Hey, this is great. It is so nice to see the uptick of interest in the #C2S part of #ActivityPub. Very uplifting and gives me hope for the future of #fediverse.
I really liked your #FOSDEM presentation, and thank you for mentioning my humble list. They are just notes atm, but I will try to keep them up-to-date. I just made a bunch of updates..
https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130
Would love to hear more on what are the particular plans and goals for your project in the near future?
This is marvelous. I wasn't aware of your project, but now I am and added it to the #ActivityPub #C2S tracking list.
I've also lined up #Outpost for inclusion on the delightful #fediverse curated lists at https://delightful.coding.social
Bring it on!
#ActivityPub Social API is getting a lot of attention and traction on the implementation side! 🎉
Join the fun, in this area where there's a fine future for the #fediverse social networking.
Some new updates to the list of client-to-server #C2S parts of the AP open standard:
https://codeberg.org/fediverse/delightful-fediverse-experience/issues/130
Added the projects of @kopper and a new C2S article by @mediaformat
@ocdtrekkie @mapache @badgefed
I was not aware of that Should #Sandstorm be added to the #ActivityPub delightful lists? An intent to implement (e.g. in an open issue) is sufficient for inclusion.
https://delightful.coding.social
@virtualpierogi @sri @jsalvador @ben
Unfortunately there's a new threat, and it was addressed in the #FOSDEM keynote speech by @michiel of @nlnet .. and that is the mad dash to incorporate #AI into everything and vibe-code stuff together in a heartbeat.
I think this is particular bad for the fediverse #SocialWeb still lacking its robust foundations. The #LLM's will have no problem figuring out how to mix'n mash the existing protocol decay and tech debt into new applications that are rushed into production. Finally non-protocol-experts are enable on the ecosystem and can onboard themselves without involving themselves in endless plumbing of the most low-level technical implemention details of #ActivityPub devs.
But the ecosystem will rot and decay as a result of it. Furthermore if a slew of AI-generated fedi apps are launched in quick succession and some of them find good uptake (until they break in unexpected ways), it will serve to attract unwanted corporate attention I'm afraid.
@virtualpierogi @sri @jsalvador @ben @nlnet
It needs concerted effort, as argued in my blog post, to set all of this up. Things can start small and pragmatic, and then gradually evolve and mature, but we should take care it evolves in the proper direction.
There are trade-offs to consider every step of the way. If there'd more capabilities to introspect the functionality that an #ActivityPub actor offers, it would diminish the need for an upfront design-by-consensus process, but it would increase the complexity of the specifications.
I drew this in a diagram a couple years ago, and transferred it to our social coding forum at: https://discuss.coding.social/t/wiki-grassroots-standardization-processes/672?u=aschrijver
Here you see the fediverse devolve into non-interoperable app-by-app whack-a-mole development, keeping track of all the moving-target #FOSS projects one took a dependency on. Versus the #SolidProject that tries to hammer out full-blown specs upfront, which became a huge package to deal with, with high complexity to implement.
@virtualpierogi @sri @jsalvador @ben @nlnet
When it comes to #interoperability there is no way around having consensus on what you interoperate on, and there must be alignment on some kind of Video related domain model that is robust and consistent.
If there were a robust #ActivityPub extension mechanism as well as good development practices and processes for the creation of extension into new business and application domains, then this mechanism can still facilitate app-specific extension on top of such a Video domain specification. It is very common for protocol design to have all kinds of extension points, look e.g. at #ATProto or #CloudEvents.
And more specialized domain extensions can also facilitate further extension in their design. Look e.g. at #ForgeFed AP extension, which allows custom forge-specific metadata collections to be sent with a federated Issue or PR.
I think we underrated the power of the actor model and the extent we can incorporate it on the #ActivityPub fediverse. Somehow we got eternally stuck in talking about HTTP plumbing and core protocol capabilities that we never fleshed out thoroughly in order to be able to just focus on the higher-level concerns of app and service modeling.
Actor systems based on loosely-coupled event-driven architecture, delegation, supervision, supervision strategies, inbox strategies, let-it-fail, actors fronting domain aggregates, service-orientation, etc.
In my opinion where it concerns social network innovation, when we continue to follow the app-centric model we have today we enter a dead-end street. Though it gives interesting applications it will not constitute the future of social networking.
To me it is really crazy that a new fedi app that, say, enters a Video domain would need to adopt Peertube namespaces in their #ActivityPub extension model. If you look at that model it is no different than taking on dependencies in regular #FOSS development. As soon as the Peertube namespace is in your project, then Peertube is in charge of that part of the design, an upstream dependency. But Peertube doesn't care about you. It is an end-user product doing their own product development.
And then things worsen when the new fedi app entry pushes their own extension properties into this ball of mud. It is a design approach that basically assures loss of interoperability and severe whack-a-mole pain to devs.
I just responded in the other thread about #ForgeFed way of dealing with Issues and PR's, emphasizing the actor model in the #ActivityPub specs.
Guess it depends on the nature of your extension and its desired functionality how you model things, but ForgeFed chose to have a dedicated actor, a TicketTracker, to manage the collection. Big advantage is that it become a truly encapsulated service with its own business logic, fronted by an AP actor for interoperable network communication.
https://social.coop/@smallcircles/116096769625606025
Right now extensibility of #ActivityPub shapes up as custom app-by-app app-centric development where individual devs just pragmatically throw new stuff on the wire, and when their app gains any popularity or other apps to integrate in a similarish application, things are bolted onto that in random ways. That whole story really constitutes a Big Ball of Mud anti-pattern that only introduces protocol decay, tech debt, and whack-a-mole programming, that is very hard to get rid of once there exists an installed base.
The reason that we do things that way is very understandable. It works in a grassroots environment where indivualist devs find it very hard and not valuable to collaborate at scale in what amounts to a kind of design-by-consensus process. But it comes at a high cost, where interoperability is basically out the door and any app has to be shaped as a pretzel and adopt all the quirks introduced by predecessors in a particular app domain to fit itself on the wire.
Yes. Mastodon has always given their own product decisions precedence over healthy evolution of the ecosystem as a whole. And despite many people being very frustrated about that, I think this is perfectly valid decision. After all choosing to implement an open standard should not come with the obligation to maintain/evolve that standard. It is only smart to do so, and Mastodon did this with an eye on their own product development.
Imho it is really the broader dev ecosystem that is at fault in letting the fedi be taken hostage by past Mastodon decisions, making them the post-facto #interoperability leader. As for Mastodon API I'd argue that its users are not on the fediverse. They are on Mastodon.
Identity management may be killer feature, but only when first a sound #ActivityPub foundation is in place. AS/AP isn't as-yet robust enough to be the future of social networking. I'd say the extensibility mechanism is killer feature, and having SDK's and devtools for that.