As #Fedify's author, I'm contemplating its adoption beyond Ghost's #ActivityPub implementation. Finding potential users for ActivityPub tools seems challenging—perhaps I'm addressing a very niche need?
While the technical complexity of ActivityPub makes tools like Fedify valuable, I wonder about the actual market demand for federation outside specific communities.
Open, decentralized systems make sense to many developers, but businesses often prefer closed ecosystems that align with traditional models.
Still, I see potential as the #fediverse grows and digital sovereignty concerns increase. Fedify aims to lower the technical barriers to federation.
I'm curious: Which projects would benefit most from Fedify today? What would make federation compelling enough for platforms to implement?
Would appreciate perspectives from both developers and platform owners.
@hongminhee I think that a library that targets the nodejs ecosystem while claiming to want to lower the technical barriers to federation is slightly contradictory.
I can perhaps understand if you mean it that it lowers the technical barriers for other nodejs developers, but in the grand scheme of things, picking something that can be deployed straight to bare metal would be more in line with your goal.
Caveat, I'm entirely biased here, because I chose Go to develop a similar library with a similar goal in mind, so I hope you don't take my critique too much to heart. :D
@mariusor @hongminhee What does "deployed straight to bare metal" mean here exactly?
@joepie91 I meant it as a physical server without the need for a run environment that needs to be set-up at provisioning time.
@mariusor @hongminhee I'm not sure I follow - why would this be any different for Node.js?
@joepie91 if you have an argument against what I just said, please bring it forward instead of playing 20 questions.
@mariusor No, I'm genuinely trying to understand what you mean here. To me, there's no relation between "deploying on bare metal" and choice of language at all, so I feel like I must be either missing or misunderstanding something.
@joepie91 OK, sorry, I suspected an attempt at bad faith baiting.
Node.js represents a run-time (based on V8 Javascript virtual machine) without which an application that requires it can't run. Unlike a binary obtained from a Go/Rust/C/etc source tree, which - when compiled for the correct target - will run directly on said target.
This means that the effort required to deploy/keep running these applications, is higher for the nodejs application.
@mariusor Hmm, where are you seeing the additional effort being involved? As there's no real operational cost to a dependency being involved, since that's typically handled by the package manager automatically.
Or are you thinking of the "no package manager, only run binaries directly on the system" case specifically?
@joepie91 I feel like this thread is not the appropriate place to have this discussion.
But to give you a final answer: the main distinction in my mind between a standalone binary and an application that requires a run-time/virtual machine/etc is in the following:
The dependency chain for a static application needs to be negotiated only once at build time, usually by the application's developer or packager.
The dependency chain for an application that requires a run-time is usually done at deploy-time... which means that it has to be done by each entity that wants to deploy it, which results in far more work being done.
@joepie91 as Hong Minhee said in a sibling comment, that's not always the case, but that was my thinking in making the distinction between the two.
@mariusor Right, I understand what you mean now. Assuming we're looking at the same sibling comment, there are indeed options in Node.js to get an equivalent deployment experience; eg. the built-in experimental SEA thing (https://nodejs.org/docs/latest/api/single-executable-applications.html) or the older vercel/pkg tool.
