#ThoughtProvoker
-
Though with regards to progress, there's a difference in both approaches.
At the #SolidProject side you have inertia by the slow standardization process. But should they figure things out in a good way, eventually the ecosystem catches up and the inertia can quickly decrease.
While at #ActivityPub side, since AS/AP remains stagnant, the ever increasing protocol decay and tech debt non-linearly increases inertia and progress. And on top of that, you are never done once you implemented the 'ad-hoc specs' of the installed base, and you have to account for continuous whack-a-mole development and maintenance burdens to fix #interoperability breakages.
The AS/AP based fediverse devolves into effectively no interoperability, and a situation that is more comporative to NPM dependency hell.
Btw, just found the v2 release announcement of @fedify and that is a prime example on how, on the grassroots environment end of the spectrum we can maneuvre into better territory.
Kudos to the #fedify developers. Handing people tools they need to focus on solutions, and build without getting thrown into deep on-the-wire impl detail reeds to worry about.
That is the positive side of the equation. There's not only a big uptick in interest for the #SocialAPI i.e. #ActivityPub client-to-server, which offers new opportunity to correct course. But also are there more #FOSS projects focused on robust tool and library support for the 'Solution developer' stakeholder.
In the revamp of the delightful commons initiative, made possible with support of @nlnet I emphasized all these projects, while I de-emphasized the apps that are already doing good for themself, but contribute to further divergence from open standards.
**Fedify 2.0.0 is here!** Thi…
**Fedify 2.0.0 is here!** This is the biggest release in Fedify's history. Here are the highlights: - **Modular architecture** — The monolithic `@fedify/fedify` package has been broken up into focused, independent packages: `@fedify/vocab`, `@fedify/vocab-runtime`, `@fedify/vocab-tools`, `@fedify/webfinger`, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types. - **Real-time debug dashboard** — The new `@fedify/debugger` package gives you a live dashboard at `/__debug__/` showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your `Federation` object and you're done. - **ActivityPub relay support** — First-class relay support via `@fedify/relay` and the `fedify relay` CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c). - **Ordered message delivery** — The new `orderingKey` option solves the “zombie post” problem where a `Delete` arrives before its `Create`. Activities sharing the same key are guaranteed to be delivered in FIFO order. - **Permanent failure handling** — `setOutboxPermanentFailureHandler()` lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever. Other changes include content negotiation at the middleware level, `@fedify/lint` for shared linting rules, `@fedify/create` for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes. This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved! This is a major release with breaking changes—please check the migration guide before upgrading. Full release notes: https://github.com/fedify-dev/fedify/discussions/580 #Fedify #ActivityPub #fediverse #fedidev #TypeScript
(hollo.social)
-
Btw, just found the v2 release announcement of @fedify and that is a prime example on how, on the grassroots environment end of the spectrum we can maneuvre into better territory.
Kudos to the #fedify developers. Handing people tools they need to focus on solutions, and build without getting thrown into deep on-the-wire impl detail reeds to worry about.
That is the positive side of the equation. There's not only a big uptick in interest for the #SocialAPI i.e. #ActivityPub client-to-server, which offers new opportunity to correct course. But also are there more #FOSS projects focused on robust tool and library support for the 'Solution developer' stakeholder.
In the revamp of the delightful commons initiative, made possible with support of @nlnet I emphasized all these projects, while I de-emphasized the apps that are already doing good for themself, but contribute to further divergence from open standards.
**Fedify 2.0.0 is here!** Thi…
**Fedify 2.0.0 is here!** This is the biggest release in Fedify's history. Here are the highlights: - **Modular architecture** — The monolithic `@fedify/fedify` package has been broken up into focused, independent packages: `@fedify/vocab`, `@fedify/vocab-runtime`, `@fedify/vocab-tools`, `@fedify/webfinger`, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types. - **Real-time debug dashboard** — The new `@fedify/debugger` package gives you a live dashboard at `/__debug__/` showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your `Federation` object and you're done. - **ActivityPub relay support** — First-class relay support via `@fedify/relay` and the `fedify relay` CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c). - **Ordered message delivery** — The new `orderingKey` option solves the “zombie post” problem where a `Delete` arrives before its `Create`. Activities sharing the same key are guaranteed to be delivered in FIFO order. - **Permanent failure handling** — `setOutboxPermanentFailureHandler()` lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever. Other changes include content negotiation at the middleware level, `@fedify/lint` for shared linting rules, `@fedify/create` for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes. This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved! This is a major release with breaking changes—please check the migration guide before upgrading. Full release notes: https://github.com/fedify-dev/fedify/discussions/580 #Fedify #ActivityPub #fediverse #fedidev #TypeScript
(hollo.social)
@fedify @hongminhee I would be delighted if #fedify contributors would take a peek at the fediverse development curated list and propose a PR on how best to incorporate the changes to the project, now that the various #TypeScript packages have been modularized. That would be very helpful. And create an issue if the current list format is no good fit.
delightful fediverse development
Delightful curated lists of free software, open science and information sources.
(delightful.coding.social)
-
@fedify @hongminhee I would be delighted if #fedify contributors would take a peek at the fediverse development curated list and propose a PR on how best to incorporate the changes to the project, now that the various #TypeScript packages have been modularized. That would be very helpful. And create an issue if the current list format is no good fit.
delightful fediverse development
Delightful curated lists of free software, open science and information sources.
(delightful.coding.social)
@smallcircles@social.coop Okay, we'll look into the list, and send pull requests!
-
I recreated an old diagram in Excalidraw that I spread about a couple years ago, and made it a bit more informative. Explanation can be found in the #AltText
See also and for discussion: https://discuss.coding.social/t/diagram-interoperability-in-practice/828
Or join the Social experience design chatroom at: https://matrix.to/#/#socialcoding-foundations:matrix.org
Also posted to #SocialHub at: https://socialhub.activitypub.rocks/t/activitypub-versus-fediverse-interoperability-in-practice/8498
#SX #SocialCoding #SocialWeb #ActivityPub #SolidProject #fediverse
@smallcircles
I remember this sentence from https://ufind.univie.ac.at/de/person.html?id=1001662, around 2013:
"Interoperability can only be proven after the fact."
@ben -
@hongminhee thank you!
-
Though with regards to progress, there's a difference in both approaches.
At the #SolidProject side you have inertia by the slow standardization process. But should they figure things out in a good way, eventually the ecosystem catches up and the inertia can quickly decrease.
While at #ActivityPub side, since AS/AP remains stagnant, the ever increasing protocol decay and tech debt non-linearly increases inertia and progress. And on top of that, you are never done once you implemented the 'ad-hoc specs' of the installed base, and you have to account for continuous whack-a-mole development and maintenance burdens to fix #interoperability breakages.
The AS/AP based fediverse devolves into effectively no interoperability, and a situation that is more comporative to NPM dependency hell.
@smallcircles @ben Unfortunately, the top-down approach often stalls under its own inertia and never develops into anything at all.
If you try for too much interoperability too fast, the costs aren't evenly distributed: some implementors will have to make very few changes (usually the ones who had the most power and influence during the standardisation process), while others will have to tear up a lot of stuff and start over.
In the business/government/aid world, that can have ripples far beyond the IT systems, right into the way they organise their operations; in the FOSS world, it can mean abandoning popular features, losing users, and even destroying the contributor culture.
An 800 lb gorilla like Walmart can force that level.of dirigisme on its suppliers, but in the open world, we can just ignore or fork if we think someone's getting too restrictive: note how most web syndicators stuck with RSS 2.0 even after Atom came along to "fix" its "problems," for example (and Atom wasn't even that bad).
-
I recreated an old diagram in Excalidraw that I spread about a couple years ago, and made it a bit more informative. Explanation can be found in the #AltText
See also and for discussion: https://discuss.coding.social/t/diagram-interoperability-in-practice/828
Or join the Social experience design chatroom at: https://matrix.to/#/#socialcoding-foundations:matrix.org
Also posted to #SocialHub at: https://socialhub.activitypub.rocks/t/activitypub-versus-fediverse-interoperability-in-practice/8498
#SX #SocialCoding #SocialWeb #ActivityPub #SolidProject #fediverse
🫧 socialcoding.. (@smallcircles@social.coop)
A developer ecosystem that has only cheerleaders is doomed.
social.coop (social.coop)
To get back to 'shared ownership' and @ben article that triggered my blog post.
The #fediverse is certainly not all cheerleaders, but the question is whether critical notes can be properly heard and addressed in any meaningful way. After all who are the ones who should hear them and act on them? It is "the herd", the crowd, the commons that happens to receive toots via their social graph, and to the extent these manage to penetrate bubbles and echo chambers. To make a strong argument, to reach people, the only strategy is social media influence marketing of sorts. You have to dare to rock the boat enough to be heard. And that's a very bad way to grow a healthy ecosystem I think.
It relates to the oft-heared criticism that on the app-centric #ActivityPub fediverse, it is the app devs who are de-facto in charge and decide what goes and what goes not.
The social dynamics are tricky but fascinating. I hope to be able to spend more time at https://coding.social
-
🫧 socialcoding.. (@smallcircles@social.coop)
A developer ecosystem that has only cheerleaders is doomed.
social.coop (social.coop)
To get back to 'shared ownership' and @ben article that triggered my blog post.
The #fediverse is certainly not all cheerleaders, but the question is whether critical notes can be properly heard and addressed in any meaningful way. After all who are the ones who should hear them and act on them? It is "the herd", the crowd, the commons that happens to receive toots via their social graph, and to the extent these manage to penetrate bubbles and echo chambers. To make a strong argument, to reach people, the only strategy is social media influence marketing of sorts. You have to dare to rock the boat enough to be heard. And that's a very bad way to grow a healthy ecosystem I think.
It relates to the oft-heared criticism that on the app-centric #ActivityPub fediverse, it is the app devs who are de-facto in charge and decide what goes and what goes not.
The social dynamics are tricky but fascinating. I hope to be able to spend more time at https://coding.social
> It is "the herd", the crowd, the commons that happens to receive toots via their social graph
I should clarify that I refer specifically to the situation as it exists now, where the dev community basically chose microblogging as their prime communication medium.
-
> It is "the herd", the crowd, the commons that happens to receive toots via their social graph
I should clarify that I refer specifically to the situation as it exists now, where the dev community basically chose microblogging as their prime communication medium.
What we need is the ability to support #ChaordicOrganization on the #ActivityPub #fediverse.
How We Reimagine the Social Web
We find novel ways to collaborate and create value together.
Social coding commons (coding.social)
-
I sometimes feel that I must be crazy, and totally off the mark, as I - and luckily others with me - are saying these things for 7 years now. But it somehow hits a wall of inertia.
It is this inertia in itself, that has started fascinating me the last 2 years, and it is the reason why https://coding.social exists. We have to figure out how to deal with the grassroots social dynamics such that healthy long-term sustainable standards, ecosystems, and online environments emerge and further evolve.
Long ago I took notes on some major challenges that in my opinion hold back the fediverse from becoming The Future of Social Networking. These are all mostly social in nature, and are as relevant today as they were then. But this is also just imho.
Major challenges for the Fediverse
Various forum topics highlights big challenges for the Fediverse to overcome. Below there is a list of those, and all of them are within scope of Social Coding #foundations to contribute to solutions. Challenge Desc…
Discuss Social Coding (discuss.coding.social)
@smallcircles "grassroots social dynamics" may be actually digital NIMBY movement against targeted advertising and AI...
@thisismissem -
@smallcircles "grassroots social dynamics" may be actually digital NIMBY movement against targeted advertising and AI...
@thisismissemI've been a long-time advocate for #HumaneTechnology. Social coding commons adds something to that to become "humane and harmonious technology". Humane by default. #Humanity is an intrinsic value of the movement. And harmonious by #SocialCoding. Coding is social, and first of all deals with people coordinating to find solutions that align with and satisfy stakeholder needs. Coding happens somewhere in the process, an impl detail.
A core principle of Social experience design is Sustainability, which is holistic in nature via the (adapted) Circles of Sustainability model. https://coding.social/blog/reimagine-social/#circles-of-sustainability
With this in place a #SX software solution will cycle through its Free software development lifecycle i.e. #FSDL, which drives a tailored development based on needs and lifecycle phase. https://coding.social/blog/reimagine-social/#free-software-development-lifecycle
Together this completely avoids a pure technology-driven development, ensuring Needs-driven development, and a natural NIMBY of inhumane technology and practices.
-
I've been a long-time advocate for #HumaneTechnology. Social coding commons adds something to that to become "humane and harmonious technology". Humane by default. #Humanity is an intrinsic value of the movement. And harmonious by #SocialCoding. Coding is social, and first of all deals with people coordinating to find solutions that align with and satisfy stakeholder needs. Coding happens somewhere in the process, an impl detail.
A core principle of Social experience design is Sustainability, which is holistic in nature via the (adapted) Circles of Sustainability model. https://coding.social/blog/reimagine-social/#circles-of-sustainability
With this in place a #SX software solution will cycle through its Free software development lifecycle i.e. #FSDL, which drives a tailored development based on needs and lifecycle phase. https://coding.social/blog/reimagine-social/#free-software-development-lifecycle
Together this completely avoids a pure technology-driven development, ensuring Needs-driven development, and a natural NIMBY of inhumane technology and practices.
@smallcircles well, but what are "human needs"? I definitely like to avoid advertisements, but at the same time I am curious and I seek new things. And humans must be motivated to share news things... applause is great motivation, but is it enough? And we need real audience, not AI bot audience....
Maybe nerd needs are not exactly human needs, in the first place...
Also, some people tend to do thing just because they want to show they can.
And also you can optimize for as little technology as possible, or for as "optimal" technology as possible.
Currently, I am not so much concerned about future of ActivityPub, which is currently adequate, as it seems.
Running my own small instance is challenging, because resources are limited and I immediately see, that focusing on fundraising and controlling more resources is not the way.
I run state-of-the art Mastodon, maintained and updated by someone who is better admin, but I rather focus on tuning it. I play with tootctl statuses, found some undocumented features (this is not very human focused, to not document useful features).
Currently I would like to fine-tune lifetime of statuses in federated cache, which are without any interactions. Algorithm may be needed, because some accounts are automated and hyper active and flood the cache with tons of content (and someone on your instance is always going to follow them).
Domain-wide bans may or may not be the solution. What I am thinking about is domain-specific or even-account specific lifetime of statuses without interaction. This would save resources. Saving resources is in the end eco-centric.
Is my approach technology-centric or human-centric? Well, I want to compete for attention of humans with machines, designed to entertain them....
-
@smallcircles well, but what are "human needs"? I definitely like to avoid advertisements, but at the same time I am curious and I seek new things. And humans must be motivated to share news things... applause is great motivation, but is it enough? And we need real audience, not AI bot audience....
Maybe nerd needs are not exactly human needs, in the first place...
Also, some people tend to do thing just because they want to show they can.
And also you can optimize for as little technology as possible, or for as "optimal" technology as possible.
Currently, I am not so much concerned about future of ActivityPub, which is currently adequate, as it seems.
Running my own small instance is challenging, because resources are limited and I immediately see, that focusing on fundraising and controlling more resources is not the way.
I run state-of-the art Mastodon, maintained and updated by someone who is better admin, but I rather focus on tuning it. I play with tootctl statuses, found some undocumented features (this is not very human focused, to not document useful features).
Currently I would like to fine-tune lifetime of statuses in federated cache, which are without any interactions. Algorithm may be needed, because some accounts are automated and hyper active and flood the cache with tons of content (and someone on your instance is always going to follow them).
Domain-wide bans may or may not be the solution. What I am thinking about is domain-specific or even-account specific lifetime of statuses without interaction. This would save resources. Saving resources is in the end eco-centric.
Is my approach technology-centric or human-centric? Well, I want to compete for attention of humans with machines, designed to entertain them....
Beyond basic needs, saying 'human needs' is a generalization. It's better to go from personal needs. #SX starts from individual needs and builds from there to take needs of all relevant stakeholders into account as they are identified during the lifecycle and evolution of a solution. Along the way there are perspective shifts, e.g. from personal needs to inter-personal relationships. See: https://coding.social/blog/reimagine-social/#pyramid-of-perspective
If you start a software project, it is perfectly fine to consider yourself the only stakeholder. E.g. if you code just for you, as a hobby, and for the joy of coding.
If you make it #FOSS and publish to a code forge, you make a certain commitment to a new stakeholder, the FOSS developer, concering software freedoms. But not more than that, unless you explicitly commit yourself, and to the extent in which there is a mutual understanding what people can expect from you.
Then yes its human-centric. More importantly it aligns with needs, offers a solution.
