My hot take is that the #ActivityStreams and #ActivityPub specs are fine. Having some more standards for working with groups might be nice but honestly I'm happy with how much folks are able to do already and how many implementations are out there that can work together. This is from a few months of working on a new implementation. Honestly there's been a decent amount of docs spread around the place to go off of.
That's really not a hot take. It's a pretty chill take.
For me the question is: Can you do something to make the entry of new developers to ActivityPub easier?
I wrote this tutorial and it seems to have helped some people. Creating a better developer experience will hopefully attract new people and thus great ideas.
@helge right now I'm focused on making it easier for web publishers to use this stuff and with all our work being in the open for devs to peek at and reuse 🥰
My wip blog post about it: https://github.com/RangerMauve/blog.mauve.moe/pull/1
Tbh these two guides and peeking at my mastodon data got me all I needed. :P
https://paul.kinlan.me/adding-activity-pub-to-your-static-site/
https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/
It was honestly trivial compared to some of the stuff out there 😅
Btw, @fedidevs has a very active matrix chatroom and #SocialHub is good place for long-form #ActivityPub discussion.
(Can't help it. Still doing some of that advocacy 😜 )
@mauve @helge @mariusor
I see you mention #P2P use of #ActivityPub which is 😎
What do you think about #C2S and rich #LocalFirst client apps I wonder, given your expertise in that last area?
Btw, I keep tabs on #WebAssembly/WASI which brings a nice buzzword spaghetti within reach 😜
Serious though. Like #polyglot development of sandboxed server-side modules that can be composed together. #Golang 1.21 recently acquired more native Wasm support, for instance.
#Spritely will bring wasm OCaps.