Developer perspective on tradeoffs… #ATProto architecture is more centralized.
General Discussion
13
Posts
4
Posters
0
Views
-
I think a problem is more that instead of "ActivityPub has JSON-LD" you might also say that AP delegates to.. or even 'handwaves' to linked data.
#ActivityPub is linked data --> ✅ Extensibility mechanism DONE"
Which is either..
- By far not the case, if you consider the promise and power of ActivityPub
- May perhaps be true, if you have a very particular notion on what the fediverse is and isn't.
That last bit remained unspoken, so what AP vs. fediverse is, is really in the eye of the beholder. There exists no shared (technology) vision. https://discuss.coding.social/t/major-challenges-for-the-fediverse/67
With the extensibility mechanism unclear, there is no clear separation either to what is protocol and what is solution space, and there's continuous confusion around this.
I replied to @evan yesterday, as his remark would entail that all post-facto interoperability introduced on-the-fly by app impls would have to be honored now in the standards. What standards process does that give?
@smallcircles It's even crazier than that. I saw the thread a few days ago where @cwebber apologized for JSON-LD in AP and @evan defended it (but for backwards-compat, not because AP is linked data). The "extensibility" claim is technical gaslighting since that's only true if you use JSON-LD processing of AP data (practically no one does and there's no requirement to do it). 🤪 Even then it's a weak form of protocol extensibility.
-
@smallcircles It's even crazier than that. I saw the thread a few days ago where @cwebber apologized for JSON-LD in AP and @evan defended it (but for backwards-compat, not because AP is linked data). The "extensibility" claim is technical gaslighting since that's only true if you use JSON-LD processing of AP data (practically no one does and there's no requirement to do it). 🤪 Even then it's a weak form of protocol extensibility.
Yes. The ad-hoc interoperability approach means that every developer is free to introduce any extension on the fly that exposes some functionality from their app on the fedi wire. They don't have to wait for anyone, or for standards to catch up. Suppose they designed it well, and now some new functionality is available for others to integrate with.
Should others do so, they have to include the app's namespace. This is saying: I accept you are leading in the specs here. It is taking an upstream dependency and not much different than what you do in JS/TS NPM and node_modules dependency hell world.
Peertube was the first to expand as:Video (not LD compliant then, dunno now) and if they have popular uptake, a newcomer in vid-related domain has a 3-fold choice for extensions:
1. accept PT de-facto standard
2. introduce my own
3. mix'n matchWhen choosing 3, the vid app that comes next can now mix'n match 2 vid platforms extensions. Good luck, future fedi.. 😬
-
Yes. The ad-hoc interoperability approach means that every developer is free to introduce any extension on the fly that exposes some functionality from their app on the fedi wire. They don't have to wait for anyone, or for standards to catch up. Suppose they designed it well, and now some new functionality is available for others to integrate with.
Should others do so, they have to include the app's namespace. This is saying: I accept you are leading in the specs here. It is taking an upstream dependency and not much different than what you do in JS/TS NPM and node_modules dependency hell world.
Peertube was the first to expand as:Video (not LD compliant then, dunno now) and if they have popular uptake, a newcomer in vid-related domain has a 3-fold choice for extensions:
1. accept PT de-facto standard
2. introduce my own
3. mix'n matchWhen choosing 3, the vid app that comes next can now mix'n match 2 vid platforms extensions. Good luck, future fedi.. 😬
The protocol becomes more like the union of all app-specific functionality that has been created over time, and copied / depended on by others in fundamental ways. Instead of that all that happens in clear solution layer that rests above the protocol conceptually.
The protocol boundaries are fuzzy.
@deadsuperhero mentioned the other day that having identity management well figured out, would be the killer app for the fediverse.
But without having these fundamentals on how we responsibly 'extend the fediverse' (deploy a new solution, deliver a service), I don't think this is the case. But having that functionality might make it very clear that we need this foundation.
Now an identity is neatly app-bound, but then no longer and since all apps overloaded the ActivityStreams social primitives you may have to deal with the full combinatorial explosion of figuring out what the functionality of your as:Video or other object really is.
Perhaps I see it wrong.
-
The protocol becomes more like the union of all app-specific functionality that has been created over time, and copied / depended on by others in fundamental ways. Instead of that all that happens in clear solution layer that rests above the protocol conceptually.
The protocol boundaries are fuzzy.
@deadsuperhero mentioned the other day that having identity management well figured out, would be the killer app for the fediverse.
But without having these fundamentals on how we responsibly 'extend the fediverse' (deploy a new solution, deliver a service), I don't think this is the case. But having that functionality might make it very clear that we need this foundation.
Now an identity is neatly app-bound, but then no longer and since all apps overloaded the ActivityStreams social primitives you may have to deal with the full combinatorial explosion of figuring out what the functionality of your as:Video or other object really is.
Perhaps I see it wrong.
@eyeinthesky @cwebber @evan @deadsuperhero
There are a couple of really great #IETF documents on protocol design and maintenance. You often see me mentioning protocol decay, which is only a paragraph in the splendid #RFC9413 Maintaining Robust Protocols.
The next section for instance is on detrimental ecosystem effects if you are either too stricly enforcing standards or are too laissez faire about them.
-
@eyeinthesky @cwebber @evan @deadsuperhero
There are a couple of really great #IETF documents on protocol design and maintenance. You often see me mentioning protocol decay, which is only a paragraph in the splendid #RFC9413 Maintaining Robust Protocols.
The next section for instance is on detrimental ecosystem effects if you are either too stricly enforcing standards or are too laissez faire about them.
@smallcircles “an interpretation that advocates for tolerating unexpected inputs is no longer considered best practice in all scenarios.” Somebody didn’t get the memo. lol
-
@smallcircles “an interpretation that advocates for tolerating unexpected inputs is no longer considered best practice in all scenarios.” Somebody didn’t get the memo. lol
Here we come to my new interest area.. I spent a metric ton of time advocating for #fediverse and #ActivityPub and that was initially all on a very optimistic note on how our ecosystem would mature and grow over time, fostering a healthy future for itself.
That however didn't go as planned. You might say that the entirety of the fediverse is still primarily tech-driven. Tech-first approaches that do not differ too much of the much reviled and rejected 'techbro approach'.
Sure, there are plenty discussions on whether an app feature is 'ethical' or not, with discussions on e.g. opt-in vs. opt-out. But that is again purely app-centric.
Where is the dev ecosystem headed, where should they focus, what externalities exist? Where do we want future #fediverse as a whole to be? What's the vision?
And then we come to the social side of things, both in the small, but also in-the-large. Technosphere aligned and subservient to Sociosphere. That is focus of https://coding.social
-
System moved this topic from Uncategorized
-
@smallcircles It's even crazier than that. I saw the thread a few days ago where @cwebber apologized for JSON-LD in AP and @evan defended it (but for backwards-compat, not because AP is linked data). The "extensibility" claim is technical gaslighting since that's only true if you use JSON-LD processing of AP data (practically no one does and there's no requirement to do it). 🤪 Even then it's a weak form of protocol extensibility.
@eyeinthesky @smallcircles @evan To be clear, I think json-ld has a lot of great ideas in it, and it's the extensibility and linked data compatibility (which was a strong group requirement) story we had at the time.
"JSON-LD is bad" doesn't really capture my views. "JSON-LD turned out to be too complicated for the majority of the ecosystem to work with, particularly when we gave the view that you could ignore it, except it creates a rift of interoperability between those who ignore it and those who don't and puts a burden on the latter who are doing their best to behave well" does match my views.
There are paths out of the situation, but I'm not confident in the discourse around them right now, and hesitant about how much I want to engage with it.
-
@eyeinthesky @smallcircles @evan To be clear, I think json-ld has a lot of great ideas in it, and it's the extensibility and linked data compatibility (which was a strong group requirement) story we had at the time.
"JSON-LD is bad" doesn't really capture my views. "JSON-LD turned out to be too complicated for the majority of the ecosystem to work with, particularly when we gave the view that you could ignore it, except it creates a rift of interoperability between those who ignore it and those who don't and puts a burden on the latter who are doing their best to behave well" does match my views.
There are paths out of the situation, but I'm not confident in the discourse around them right now, and hesitant about how much I want to engage with it.
@cwebber @eyeinthesky @smallcircles @evan Apart from the fact that I would prefer turtle, I am very happy that AP ‘prescribes’ json-ld. This opens the door to many of my ideas. It makes possible what would be very complicated without #RDF. It's about time that the AP developers got to grips with it! https://rdf-pub.org/#rdf
-
Developer perspective on tradeoffs… #ATProto architecture is more centralized. #ActivityPub has JSON-LD. ⚖️ So much pain and confusion, so little benefit and the Fedi Father refuses to consider JSON-LD alternatives because replacing the “feature” that almost no one actually uses with something useful will apparently break the Fediverse.
“This is why we can’t have nice things.” 😬#fedidevs
@eyeinthesky The reason we can't have nice things is because the Fedi Devs don't want to deal with the basics of the protocol. Or: Because no one has yet provided C2S for Fedi Devs who don't want to deal with the basics.
-
@eyeinthesky @smallcircles @evan To be clear, I think json-ld has a lot of great ideas in it, and it's the extensibility and linked data compatibility (which was a strong group requirement) story we had at the time.
"JSON-LD is bad" doesn't really capture my views. "JSON-LD turned out to be too complicated for the majority of the ecosystem to work with, particularly when we gave the view that you could ignore it, except it creates a rift of interoperability between those who ignore it and those who don't and puts a burden on the latter who are doing their best to behave well" does match my views.
There are paths out of the situation, but I'm not confident in the discourse around them right now, and hesitant about how much I want to engage with it.
> There are paths out of the situation, but I'm not confident in the discourse around them right now, and hesitant about how much I want to engage with it.
Yes. I posted something on the same subject today.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
> There are paths out of the situation, but I'm not confident in the discourse around them right now, and hesitant about how much I want to engage with it.
Yes. I posted something on the same subject today.
-
@eyeinthesky The reason we can't have nice things is because the Fedi Devs don't want to deal with the basics of the protocol. Or: Because no one has yet provided C2S for Fedi Devs who don't want to deal with the basics.
-
@cwebber @eyeinthesky @smallcircles @evan Apart from the fact that I would prefer turtle, I am very happy that AP ‘prescribes’ json-ld. This opens the door to many of my ideas. It makes possible what would be very complicated without #RDF. It's about time that the AP developers got to grips with it! https://rdf-pub.org/#rdf
-
@eyeinthesky @smallcircles @evan To be clear, I think json-ld has a lot of great ideas in it, and it's the extensibility and linked data compatibility (which was a strong group requirement) story we had at the time.
"JSON-LD is bad" doesn't really capture my views. "JSON-LD turned out to be too complicated for the majority of the ecosystem to work with, particularly when we gave the view that you could ignore it, except it creates a rift of interoperability between those who ignore it and those who don't and puts a burden on the latter who are doing their best to behave well" does match my views.
There are paths out of the situation, but I'm not confident in the discourse around them right now, and hesitant about how much I want to engage with it.
-
Here we come to my new interest area.. I spent a metric ton of time advocating for #fediverse and #ActivityPub and that was initially all on a very optimistic note on how our ecosystem would mature and grow over time, fostering a healthy future for itself.
That however didn't go as planned. You might say that the entirety of the fediverse is still primarily tech-driven. Tech-first approaches that do not differ too much of the much reviled and rejected 'techbro approach'.
Sure, there are plenty discussions on whether an app feature is 'ethical' or not, with discussions on e.g. opt-in vs. opt-out. But that is again purely app-centric.
Where is the dev ecosystem headed, where should they focus, what externalities exist? Where do we want future #fediverse as a whole to be? What's the vision?
And then we come to the social side of things, both in the small, but also in-the-large. Technosphere aligned and subservient to Sociosphere. That is focus of https://coding.social
-
@smallcircles “an interpretation that advocates for tolerating unexpected inputs is no longer considered best practice in all scenarios.” Somebody didn’t get the memo. lol
-
@eyeinthesky @cwebber @evan @deadsuperhero
There are a couple of really great #IETF documents on protocol design and maintenance. You often see me mentioning protocol decay, which is only a paragraph in the splendid #RFC9413 Maintaining Robust Protocols.
The next section for instance is on detrimental ecosystem effects if you are either too stricly enforcing standards or are too laissez faire about them.
-
The protocol becomes more like the union of all app-specific functionality that has been created over time, and copied / depended on by others in fundamental ways. Instead of that all that happens in clear solution layer that rests above the protocol conceptually.
The protocol boundaries are fuzzy.
@deadsuperhero mentioned the other day that having identity management well figured out, would be the killer app for the fediverse.
But without having these fundamentals on how we responsibly 'extend the fediverse' (deploy a new solution, deliver a service), I don't think this is the case. But having that functionality might make it very clear that we need this foundation.
Now an identity is neatly app-bound, but then no longer and since all apps overloaded the ActivityStreams social primitives you may have to deal with the full combinatorial explosion of figuring out what the functionality of your as:Video or other object really is.
Perhaps I see it wrong.
