Now on stage, the man who published the very first post on the #SocialWeb in May 2008 and is often called the father of the #Fediverse: Evan Prodromou 
@evanEvan Prodromou Co-author of the #ActivityPub protocol at @swf
He presents the structure and dynamics of the social web, including the benefits and disadvantages of this architecture, the products and protocols, people and organizations involved in its development.
#FediMTL #DigitalSovereignty
What if... you had one Fedi account on a generic headless #ActivityPub server that simply hosts and federates your data... and had C2S UIs for microblogging, long form writing, media editing and sharing, link aggregation, games, fitness tracking, and so on, that all used that same Fedi account. Technically, it's a similar concept as ATProto (but no relay and app view) and Solid Pods (but no RDF).
It seems possible... if we can improve the AP C2S API/protocol sufficiently.
@steveSteve Bate seems possible to me too, and is also the premise of Protosocial #ActivityPub extension.
What if... you had one Fedi account on a generic headless #ActivityPub server that simply hosts and federates your data... and had C2S UIs for microblogging, long form writing, media editing and sharing, link aggregation, games, fitness tracking, and so on, that all used that same Fedi account. Technically, it's a similar concept as ATProto (but no relay and app view) and Solid Pods (but no RDF).
It seems possible... if we can improve the AP C2S API/protocol sufficiently.
#Mastodon, a #decentralised #socialmedia platform, is introducing #newfeatures to attract creators and make the platform more approachable for newcomers.
🎉 These updates include a #redesigned user profile, an enhanced compose experience, and new admin tools for server operators.
💆 The changes aim to #promote #smallinstances and make the onboarding process more understandable.
👉 https://techcrunch.com/2026/02/18/mastodon-a-decentralized-alternative-to-x-plans-to-target-creators-with-new-features/?Fedizen.EU #Fedizen #Fediverse #ActivityPub #News
@smallcircles🫧 socialcoding.. should PeerTube, Mastodon, Pixelfed, Loops, Bonfire and others merge in a single platform where a topic is more central, and not so much a file format?
Social coding commons at https://coding.social considers the online #SocialNetwork to offer a person integral social experiences. As they navigate the #SocialWeb their needs are satisfied by interoperable solutions, provided by apps and services that are delivered to the network. Social experience design #SX drives both the evolution of the technology base, as well as evolution of the ecosystem responsible for cocreating it. This results in a social-first approach focused on service delivery.
Current app-centric #fediverse follows a tech-first maturity model where app needs are leading. Individual app's requirements and features are source of truth, and secondary concern is 'pushing that on the wire'. Apps evolve as siloes independently of each other, and deal with interop issues later (and all the time, a continuous process as there is no real standard way).
So this merging will be very hard. The #ActivityPub API offers opportunity to improve ecosystem development methods.
A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent
a follow request—but the Accept never came back, even though they hadn't
enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.
I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.
This matters because Fedify implements a double-knocking mechanism—if a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.
I filed two issues on the Bonfire #ActivityPub repo—one requesting RFC 9421 support, and one about returning 401 on invalid signatures. For the latter, I also sent a PR, which got merged pretty quickly: bonfire-networks/activity_pub#9.
That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.
One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as “supports RFC 9421”—because they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.
After all that, the mutual follow went through and my DM reply landed. Worth it.
#HolosDiscover is back, from a clean slate.
A #Fediverse search engine that uses standard #ActivityPub federation. It follows you like any account, respects indexable flags, #nobot, #noindex, locked accounts. Deletions, edits, blocks are processed instantly through ActivityPub.
You have full control. Block it, mention it with "unfollow", or disable indexing in your settings.
Source code under AGPL-3.0 on #Codeberg.
Details: https://discover.holos.social/how-it-works
Account: @HolosDiscover
What is the process of publishing #ActivityPub “notes” in the W3C SocialCG or one of its Task Forces (if it’s a different answer)?
Perhaps useful, so just bringing it up. The #Makepad team are in their presentations always particularly proud in how they make #Rust builds in mere seconds across the full range of compile targets. They make builds after live coding *during* the presentation. Perhaps some of their methods to achieve this are applicable for you. Other than that, watching a recent Makepad presentation is inspiring, as their project is an impressive feat.
Btw, #Robrius uses Makepad and perhaps has similar approach to compiles, idk really. It is another cool initiative, who build #Robrix a matrix client with their app framework.
Other than that, some musings..
Your project looks very nice. Kudos! However, the past couple years I've probably seen a quadrillion instant messenger projects pass by. The screenshot on the website is "yet another familiar IM chat UI".
But if I just read your tagline of "Decentralized #P2P encrypted messaging" and I close my eyes a bit, I can picture 'universal messaging' and see something very powerful.
In #ActivityPub conceptual architecture this exists in theory, but the #fediverse diverges from that. In #XMPP and #Matrix protocol realms you hear people say "you can build any social networking use case with the protocol", but then all the documentation and discussions relate narrowly to IM and some of the hardwired abstractions assume IM (like Room in matrix).
With universal messaging I might be empowered with https://eventmodeling.org and https://eventcatalog.dev like solution design, using SDK's on top of a robust p2p protocol component. To model IM and more.
@eyeintheskyThe Eye @smallcircles🫧 socialcoding.. @evanEvan Prodromou 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.
@cwebberChristine Lemmer-Webber @eyeintheskyThe Eye @smallcircles🫧 socialcoding.. @evanEvan Prodromou 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
> 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.
https://coding.social/blog/reimagine-social/#chaordic-organization
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
https://social.coop/@smallcircles/116119514853649098
To get back to 'shared ownership' and 
@benBen Werdmuller 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
@smallcircles🫧 socialcoding.. “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
@eyeintheskyThe Eye @cwebberChristine Lemmer-Webber @evanEvan Prodromou
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.
@deadsuperheroSean Tilley 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.
@eyeintheskyThe Eye @cwebberChristine Lemmer-Webber @evanEvan Prodromou @deadsuperheroSean Tilley
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.
Frank Goossens' blog @frank@blog.futtta.be
Being the web performance zealot I am, I strive to having as little JavaScript on my sites as possible. JavaScript after all has to be downloaded and has to be executed, so extra JS will always have a performance impact even when in the best of circumstances it exceptionally does not impact Core Web Vitals (which are a snapshot of the bigger performance and sustainability picture). Hence when adding blocks in WordPress, I check if the block is entirely rendered server-side and if not I look […]
Read more →So #Loops features on Hacker News, having 245 comments rn. Many fedizens revile HN, for reasons I well understand.
It's still interesting to look into this thread and distill some product feedback for Loops' improvement.
https://news.ycombinator.com/item?id=47113618
HN is often blamed for having only techbro's with growth-hack mentality, with no moral compass or ethics.
Yet in the comments most concerns *are* about the #ethics of creating an #Activityub federated #FOSS TikTok, even without the addictive algorithm. Worried that short-form vids as snacks for the brain are already detrimental to people's mental health.
Some good feedback to ponder on..
Though I also observe a general misunderstanding how loops differs from TikTok, and the website doesn't explain that well enough. I'd make general public ("users") the prime audience served on the frontpage, who are hardly addressed atm. Then have a separate Creators header menu section. Then a Values section that also gives background to tech benefits.
To name just one example, where I think there exists a typical use case where #Loops can shine wrt #TikTok is personal Loops for friends and family. Friend of a friend personal social networking.
People make lotsa short vids with their mobile, when going on holiday and do all the things that make life worth living. And currently they share it in #BigTech's apps. Send that vid via #Whatsapp. Or place it on #Facebook or #Instagram.
But it would be perfect short-form content in the family's online corner of the web. Put some more integration with other #ActivityPub apps and services in the mix, and they have a full-service alternative to Big Tech stuffz at their disposal.
This is a different use case than how Loops is currently positioned most of all. It emphasizes the Creator. Creators have a need to publish, to reach audiences, to monetize and be able to live from their work.
The personal social networking case is for me personally the more attractive one.
#Thefediverse is a #decentralised #socialmedia network where users can interact across different platforms and servers.
🙌 It offers advantages like increased #resilience against censorship and enhanced user #privacy.
🎭 While it could simplify #contentcreation and audience growth for #influencers, it still requires #creators to tailor #content to each platform.
👉 https://mashable.com/article/what-is-the-fediverse?Fedizen.EU #Fedizen #Fediverse #ActivityPub #News
@eyeintheskyThe Eye indeed.
There's a parallel thread on the merits of linked data, that I just gave a couple follow-ups to..
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 @evanEvan Prodromou 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?
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
@thisismissemEmelia 
@mfru🍉 max frühschütz – нет войне
In your opinion, did you feel that the complexity of Solid was ONLY due to JSON-LD?
Or, were there other (non- JSON-LD) things that made it complex, too?
@reiver@reiver ⊼ (Charles) 
@thisismissemEmelia @mfru🍉 max frühschütz – нет войне
I made a diagram yesterday that contrasts #ActivityPub and #SolidProject that is I think interesting to consider.
In the past I've been very active on the Solid forum, and tried to get a collab going with #SocialHub community. A number of points that existed then, are still issues today I think.
Like, though anyone could participate in the standards process via chat, the Solid team and Inrupt were not really interested in their community, hardly giving attention while people were building interesting stuff there.
Also at the time basically all available code was Javascript, making Solid uninteresting or hard to access for other language devs.
But I think biggest issue was that Solid didn't know what it was. It was positioned as 'personal data vault' on the landing page then (but not using this term), but was 'secretly' TBL's desire to reboot the #SemanticWeb. The new web would be all 'Solid apps'. But the adoption strategy for that didn't exist.
ActivityPub client developer experience is something like this.
Building a coherent feed with stateful objects requires comparing an Activity from the inbox, with what’s in your outbox.
RE: https://mastodon.social/@reiver/112133984854710390
"A guide to implement ActivityPub in a static site (or any website)" by 
@mapacheMaho 🦝🍻
https://maho.dev/2024/02/a-guide-to-implement-activitypub-in-a-static-site-or-any-website/
Steal this idea: an app that combines YouTube and 
@peertube into a single YouTube-like interface that treats content from both as equals. Where duplicates exist, PeerTube gets priority by default. Throw in some options for patronizing creators on PeerTube, and it could motivate them to migrate to and stay on decentralized platforms.
Even better if self-hosted with Invidious on the backend.
I suspect that there is an error in the Turtle specification, in the section shown in the screen-shot.
(It relates to JSON-LD, which ActivityPub / ActivityStreams is built on.)
I suspect that "PN_CHARS_BASE" is an error.
Because other parts of other specifications seem to not make sense if it is.
I suspect that maybe it should have been "PN_PREFIX" instead.
are people on here that have opinions about #Solid (the pod technology not the javascript framework / library)
why is it good / not good?
is it usable?
is it in use?
it doesn't seem to have the same popularity as i.e. #ActivityPub / the #Fediverse, even though the concept of solid pods seems to synergize quite well with the idea of a decentralized web, as far as i can tell
Hi #fediverse and #ActivityPub developers!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
You are now two clicks away from being able to interact with my #fedify2 #indiekit implementation from your own #activitypub instance.
Yes I totally got inspired from 
@phanpy or 
@Mastodon ability to facilitate interactions between different servers
#MastoBlaster has its own #Fediverse account - powered by #snac
Follow 
@mastoblasterMastoBlaster - Official Account to receive all the updates, insights, etc.
JSON vs IETF JSON
This is likely (directly or indirectly) the fault of a single paragraph in IETF RFC-7159 / RFC-8259 (shown in the attached screen-shot).
(And note that, there is a difference between JSON and IETF JSON. JSON did not have this. IETF JSON does.)
That paragraph (in the IETF RFC) was NOT a requirement. But, others made it a requirement — including JSON-LD.
![This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.](https://files.mastodon.social/media_attachments/files/116/115/591/179/625/618/original/23d4cdfb3d03fcd9.png)
There is a larger discussion about fixed-point numbers versus floating-point numbers.
And that, ALL programming-languages should have fixed-point numbers built into them.
And that, programmers should be warned against using floating-point numbers in all but a set of very specialized situations — where inexact math is OK.
For most programmers in most situations inexact math is NOT OK. And, they should NOT use floating-point numbers.
This is from the JSON-LD spec.
ActivityPub / ActivityStream are based on JSON-LD.
I think it was a very bad idea for JSON-LD to define "number" this way!
It makes it so numbers with fractional values are inexact & lossy.
This include values that are common for money.
For example, neither 0.10 and 0.20 can be represented exactly. So, 0.10 + 0.20 does NOT equal 0.30!
It should have used FIXED-point numbers rather than FLOATING-point.
![number
In the JSON serialization, a number is similar to that used in most programming languages, except that the octal and hexadecimal formats are not used and that leading zeros are not allowed. In the internal representation, a number is equivalent to either a long or double, depending on if the number has a non-zero fractional part (see [WEBIDL]).](https://files.mastodon.social/media_attachments/files/116/115/532/009/836/539/original/5d2ac605cf834ed1.png)
JSON vs IETF JSON
This is likely (directly or indirectly) the fault of a single paragraph in IETF RFC-7159 / RFC-8259 (shown in the attached screen-shot).
(And note that, there is a difference between JSON and IETF JSON. JSON did not have this. IETF JSON does.)
That paragraph (in the IETF RFC) was NOT a requirement. But, others made it a requirement — including JSON-LD.
This is from the JSON-LD spec.
ActivityPub / ActivityStream are based on JSON-LD.
I think it was a very bad idea for JSON-LD to define "number" this way!
It makes it so numbers with fractional values are inexact & lossy.
This include values that are common for money.
For example, neither 0.10 and 0.20 can be represented exactly. So, 0.10 + 0.20 does NOT equal 0.30!
It should have used FIXED-point numbers rather than FLOATING-point.
@kopperkopper 
@gugurumbeVivien (toujours dans le déni)
Anyway, to me, a backwards-incompatible change is absolutely the worst possible choice we could make for the Fediverse. It splits the network, possibly permanently. We have about 100 implementations of ActivityPub, and they can't all upgrade at the same time.
@evanEvan Prodromou @kopperkopper @gugurumbeVivien (toujours dans le déni)
I do note that you argue for backwards "Fediverse-compatibility" here, and I wonder how that equates with backwards #ActivityPub compatibiity.
working on writing FEDERATION.md i already found one easily fixable deviation (siteName instead of nodeName in nodeinfo).
@toddsundsted very nice work! This is valuable information. #ActivityPub #FEP
Btw. #GrassrootsStandards and standardization processes (such as the #FEP process) are a topic of Social coding commons and Social experience design, and we have a multi-author blog at https://coding.social ..
If you wish you might publish these results there as a report to spread about.
Before creating and publishing FEDERATION.md for #ktistec I wanted to understand what existing practice looked like across the Fediverse.
FEP-67ff describes the requirements of the FEDERATION.md file in loose terms and provides a non-normative template. I scraped the URLs of FEDERATION.md files from FEP-67ff itself and confirmed I could fetch them. The FEP listed 30 accessible projects (31 total, but one project—FIRM—does not appear to exist).
If a file had a section with the heading "Supported FEPs" per the non-normative template, I only looked there for supported FEPs. Otherwise I scanned the entire document.
Implemented FEPs, ranked by the number of implementations that attest support, are:
FEP Name # ---- --------------------------------------------------------- -- 67ff FEDERATION.md 18 f1d5 NodeInfo in Fediverse Software 16 8b32 Object Integrity Proofs 7 044f Consent-respecting quote posts 7 2677 Identifying the Application Actor 7 e232 Object Links 6 1b12 Group federation 6 3b86 Activity Intents 6 521a Representing actor's public keys 5 2c59 Discovery of a Webfinger address from an ActivityPub actor 5 7888 Demystifying the context property 5 5feb Search indexing consent for actors 5 4adb Dereferencing identifiers with webfinger 4 d556 Server-Level Actor Discovery Using WebFinger 4 fb2a Actor metadata 4 ef61 Portable Objects 4 8fcf Followers collection synchronization across servers 4 844e Capability discovery 4 7628 Move actor 3 61cf The OpenWebAuth Protocol 3 c390 Identity Proofs 3 400e Publicly-appendable ActivityPub collections 3 c0e0 Emoji reactions 3 0151 NodeInfo in Fediverse Software (2025 edition) 3 fffd Proxy Objects 2 f228 Backfilling conversations 2 fe34 Origin-based security model 2 eb48 Hashtags 2 171b Conversation Containers 2 a5c5 Web Syndication Methods 2
There are obvious flaws in the methodology. Or maybe in the data. Only 18 out of the 30 projects I could access had a FEDERATION.md that attested FEDERATION.md support. Only 19 mentioned "FEDERATION.md". Only 21 mentioned "67ff". The remaining projects clearly did support FEP-67ff—the file itself was evidence. (FEDERATION.md is not meant to be machine readable—there's an issue about that).
It was more difficult to rank implemented federation protocols. I extracted keywords from documents with a "Supported federation protocols and standards" section and created a dictionary of terms. If a file had a section with the heading "Supported federation protocols and standards", I only looked there. Otherwise I scanned the entire document.
Feature # ---------------- -- activitypub 26 webfinger 24 http_signatures 21 nodeinfo 19 json_ld 2 ld_signatures 2 ostatus 2 authorized_fetch 1 atproto 1
If time allows, I'm going to try to rank these documents by "utility", though I haven't yet determined the exact metric. These documents clearly provide valuable information, but their lack of standardization makes them harder to analyze systematically.
@toddsundsted very nice work! This is valuable information. #ActivityPub #FEP
Before creating and publishing FEDERATION.md for #ktistec I wanted to understand what existing practice looked like across the Fediverse.
FEP-67ff describes the requirements of the FEDERATION.md file in loose terms and provides a non-normative template. I scraped the URLs of FEDERATION.md files from FEP-67ff itself and confirmed I could fetch them. The FEP listed 30 accessible projects (31 total, but one project—FIRM—does not appear to exist).
If a file had a section with the heading "Supported FEPs" per the non-normative template, I only looked there for supported FEPs. Otherwise I scanned the entire document.
Implemented FEPs, ranked by the number of implementations that attest support, are:
FEP Name # ---- --------------------------------------------------------- -- 67ff FEDERATION.md 18 f1d5 NodeInfo in Fediverse Software 16 8b32 Object Integrity Proofs 7 044f Consent-respecting quote posts 7 2677 Identifying the Application Actor 7 e232 Object Links 6 1b12 Group federation 6 3b86 Activity Intents 6 521a Representing actor's public keys 5 2c59 Discovery of a Webfinger address from an ActivityPub actor 5 7888 Demystifying the context property 5 5feb Search indexing consent for actors 5 4adb Dereferencing identifiers with webfinger 4 d556 Server-Level Actor Discovery Using WebFinger 4 fb2a Actor metadata 4 ef61 Portable Objects 4 8fcf Followers collection synchronization across servers 4 844e Capability discovery 4 7628 Move actor 3 61cf The OpenWebAuth Protocol 3 c390 Identity Proofs 3 400e Publicly-appendable ActivityPub collections 3 c0e0 Emoji reactions 3 0151 NodeInfo in Fediverse Software (2025 edition) 3 fffd Proxy Objects 2 f228 Backfilling conversations 2 fe34 Origin-based security model 2 eb48 Hashtags 2 171b Conversation Containers 2 a5c5 Web Syndication Methods 2
There are obvious flaws in the methodology. Or maybe in the data. Only 18 out of the 30 projects I could access had a FEDERATION.md that attested FEDERATION.md support. Only 19 mentioned "FEDERATION.md". Only 21 mentioned "67ff". The remaining projects clearly did support FEP-67ff—the file itself was evidence. (FEDERATION.md is not meant to be machine readable—there's an issue about that).
It was more difficult to rank implemented federation protocols. I extracted keywords from documents with a "Supported federation protocols and standards" section and created a dictionary of terms. If a file had a section with the heading "Supported federation protocols and standards", I only looked there. Otherwise I scanned the entire document.
Feature # ---------------- -- activitypub 26 webfinger 24 http_signatures 21 nodeinfo 19 json_ld 2 ld_signatures 2 ostatus 2 authorized_fetch 1 atproto 1
If time allows, I'm going to try to rank these documents by "utility", though I haven't yet determined the exact metric. These documents clearly provide valuable information, but their lack of standardization makes them harder to analyze systematically.
@david_megginson @benBen Werdmuller
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.
@david_megginson @benBen Werdmuller
Btw, just found the v2 release announcement of 
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.
https://delightful.coding.social
https://hollo.social/@fedify/019c8521-92ef-7d5f-be4d-c50eae575742
"Fedify 2.0.0 está aqui!
Esta é a maior atualização da história do Fedify. Destaques:
**Arquitetura modular** – O pacote monolítico `@fedify/fedify` foi dividido em pacotes independentes e focados: `@fedify/vocab`, `@fedify/vocab-runtime`, `@fedify/vocab-tools`, `@fedify/webfinger` e outros. Pacotes menores, imports mais limpos e a possibilidade de estender o ActivityPub com tipos de vocabulário personalizados.
**Painel de depuração em tempo real** – O novo pacote `@fedify/debugger` oferece um dashboard ao vivo em `/__debug__/` que mostra todo o tráfego de federação: traces, detalhes das atividades, verificação de assinaturas e logs correlacionados. Basta envolver seu objeto `Federation` e pronto.
**Suporte a relay do ActivityPub** – Suporte nativo a relays via `@fedify/relay` e o comando CLI `fedify relay`. Compatível com os protocolos Mastodon-style e LitePub-style (FEP-ae0c).
**Entrega ordenada de mensagens** – A nova opção `orderingKey` resolve o problema do "post zumbi", quando um `Delete` chega antes do seu `Create`. Atividades com a mesma chave são entregues garantidamente na ordem FIFO.
**Tratamento de falhas permanentes** – `setOutboxPermanentFailureHandler()` permite reagir quando uma inbox remota retorna 404 ou 410, possibilitando limpar seguidores inacessíveis em vez de tentar reenviar indefinidamente.
Outras novidades incluem negociação de conteúdo no nível do middleware, `@fedify/lint` para regras compartilhadas de linting, `@fedify/create` para scaffolding rápido de projetos, arquivos de configuração para a CLI, suporte nativo à CLI em Node.js/Bun e diversos fixes de bugs.
Esta versão conta com contribuições significativas de participantes do OSSCA da Coreia. Agradecemos imensamente a todos envolvidos!
Trata-se de uma release major com breaking changes. Consulte o guia de migração antes de atualizar.
Notas completas da release: https://github.com/fedify-dev/fedify/discussions/580
#Fedify #ActivityPub #fediverso #fedidev #TypeScript"
@fediverseFediverso 
@tecnologia 
@academicosAcadêmicos do Fediverso 
@internet (pode seguir para acompanhar os assuntos ou marcar para amplificar a postagem até no #lemmy tb)
@david_megginson @benBen Werdmuller
Yes, I agree. Though the diagram is too simple to capture it well, it is important to identify the forces that are at play, and the mechanics that drive them, and to subsequently monitor where you are and where you want to be in the future. So timely action can be taken to make corrective actions.
For the #SolidProject ecosystem for instance they might have identified a minimum set of standards to adopt, with which reasonably powerful "MVP's of the Semantic web" could be approximated with. And focus on strong library and tool support for that in multiple programming environments. Instead you enter a jungle of open stardards in various stages of completion, and good luck go figure it out. Also they might've focused on actual movement building. Far-reaching innovative standards - a new paradigm for the web - aren't adopted by the boardroom of a company, but are introduced by devs who get excited by what see and how they are empowered. And persuade management.
@david_megginson @benBen Werdmuller
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.
Fedify 2.0.0을 릴리스했습니다!
Fedify 역사상 가장 큰 릴리스입니다. 주요 변경 사항을 소개합니다:
@
@
@fedify/fedify 패키지를 @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger 등 독립적인 패키지들로 분리했습니다. 번들 크기가 줄어들고, 임포트가 깔끔해지며, 커스텀 어휘 타입으로 ActivityPub을 확장할 수도 있습니다.@fedify/debugger 패키지로 /__debug__/ 경로에 라이브 대시보드를 띄울 수 있습니다. 연합 트래픽의 트레이스, 액티비티 상세, 서명 검증, 로그까지 한눈에 확인할 수 있습니다. 기존 Federation 객체를 감싸기만 하면 됩니다.@fedify/relay 패키지와 fedify relay CLI 명령어로 릴레이 서버를 바로 띄울 수 있습니다. Mastodon 방식과 LitePub 방식 모두 지원합니다(FEP-ae0c).orderingKey 옵션으로 “좀비 포스트” 문제를 해결합니다. Delete가 Create보다 먼저 도착하는 문제가 더 이상 발생하지 않습니다. 같은 키를 공유하는 액티비티는 FIFO 순서가 보장됩니다.setOutboxPermanentFailureHandler()로 원격 인박스가 404나 410을 반환할 때 대응할 수 있습니다. 도달 불가능한 팔로워를 정리하는 등의 처리가 가능합니다.이 외에도 미들웨어 수준의 콘텐츠 협상, @fedify/lint, @fedify/create, CLI 설정 파일, 네이티브 Node.js/Bun CLI 지원, 다수의 버그 수정 등이 포함되어 있습니다.
이번 릴리스에는 한국 OSSCA (오픈소스 컨트리뷰션 아카데미) 참가자분들의 큰 기여가 담겨 있습니다. 참여해 주신 모든 분께 감사드립니다!
브레이킹 체인지가 포함된 메이저 릴리스입니다. 업그레이드 전에 마이그레이션 가이드를 꼭 확인해 주세요.
전체 릴리스 노트: https://github.com/fedify-dev/fedify/discussions/580
Fedify 2.0.0をリリースしました！
Fedify史上最大のリリースです。主な変更点をご紹介します：
@fedify/fedifyパッケージを、@fedify/vocab、@fedify/vocab-runtime、@fedify/vocab-tools、@fedify/webfingerなど、独立したパッケージに分割しました。バンドルサイズの削減、インポートの整理に加え、カスタム語彙型によるActivityPubの拡張も可能になりました。@fedify/debuggerパッケージにより、/__debug__/パスにライブダッシュボードを表示できます。連合トラフィックのトレース、アクティビティの詳細、署名検証、ログまで一目で確認できます。既存のFederationオブジェクトをラップするだけで使えます。@fedify/relayパッケージとfedify relayCLIコマンドで、リレーサーバーをすぐに立ち上げることができます。Mastodon方式とLitePub方式の両方に対応しています（FEP-ae0c）。orderingKeyオプションにより、「ゾンビ投稿」問題を解決しました。DeleteがCreateより先に到着してしまう問題がなくなります。同じキーを共有するアクティビティはFIFO順序が保証されます。setOutboxPermanentFailureHandler()で、リモートのインボックスが404や410を返した際に対応できるようになりました。到達不能なフォロワーの整理などが可能です。その他にも、ミドルウェアレベルでのコンテンツネゴシエーション、@fedify/lint、@fedify/create、CLI設定ファイル、ネイティブNode.js/Bun CLIサポート、多数のバグ修正などが含まれています。
今回のリリースには、韓国のOSSCA（オープンソースコントリビューションアカデミー）参加者の皆さんからの多大な貢献が含まれています。ご協力いただいた全ての方に感謝いたします！
破壊的変更を含むメジャーリリースです。アップグレード前にマイグレーションガイドを必ずご確認ください。
リリースノート全文: https://github.com/fedify-dev/fedify/discussions/580
Fedify 2.0.0 is here!
This is the biggest release in Fedify's history. Here are the highlights:
@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.@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.@fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).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.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 2.0.0을 릴리스했습니다!
Fedify 역사상 가장 큰 릴리스입니다. 주요 변경 사항을 소개합니다:
@fedify/fedify 패키지를 @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger 등 독립적인 패키지들로 분리했습니다. 번들 크기가 줄어들고, 임포트가 깔끔해지며, 커스텀 어휘 타입으로 ActivityPub을 확장할 수도 있습니다.@fedify/debugger 패키지로 /__debug__/ 경로에 라이브 대시보드를 띄울 수 있습니다. 연합 트래픽의 트레이스, 액티비티 상세, 서명 검증, 로그까지 한눈에 확인할 수 있습니다. 기존 Federation 객체를 감싸기만 하면 됩니다.@fedify/relay 패키지와 fedify relay CLI 명령어로 릴레이 서버를 바로 띄울 수 있습니다. Mastodon 방식과 LitePub 방식 모두 지원합니다(FEP-ae0c).orderingKey 옵션으로 “좀비 포스트” 문제를 해결합니다. Delete가 Create보다 먼저 도착하는 문제가 더 이상 발생하지 않습니다. 같은 키를 공유하는 액티비티는 FIFO 순서가 보장됩니다.setOutboxPermanentFailureHandler()로 원격 인박스가 404나 410을 반환할 때 대응할 수 있습니다. 도달 불가능한 팔로워를 정리하는 등의 처리가 가능합니다.이 외에도 미들웨어 수준의 콘텐츠 협상, @fedify/lint, @fedify/create, CLI 설정 파일, 네이티브 Node.js/Bun CLI 지원, 다수의 버그 수정 등이 포함되어 있습니다.
이번 릴리스에는 한국 OSSCA (오픈소스 컨트리뷰션 아카데미) 참가자분들의 큰 기여가 담겨 있습니다. 참여해 주신 모든 분께 감사드립니다!
브레이킹 체인지가 포함된 메이저 릴리스입니다. 업그레이드 전에 마이그레이션 가이드를 꼭 확인해 주세요.
전체 릴리스 노트: https://github.com/fedify-dev/fedify/discussions/580
Fedify 2.0.0 is here!
This is the biggest release in Fedify's history. Here are the highlights:
@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.@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.@fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).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.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
To chain things together a bit on this fleety medium of ours, create a hyperweb 😜 I'll quote this toot to follow-up to
https://social.coop/@smallcircles/116110545919004233
I remember about 2018 or so, when I joined my first #SocialCG meetup. It was when the CG was still strongly tied to #SocialHub community.
There were mundane items on the agenda, interesting to any #ActivityPub dev, and also the call to action was "whether you are technical or not at all, join the meetup, we are open and inclusive to all fedizens". Very friendly, good vibes.
However during the session the talk was not only CS expert level, but dealing with subject matter nowhere near the spec. It was 'wire reality' slang, and to learn it the guidance was either nowhere, or everywhere, dispersed. And this is still as it is today. To expertised AP developers their domain language sounds all natural, but it likely seems Martian to a dev newcomer.
Stark contrast to the W3C specs that leave folks with refreshing "Let's implement this" vibe.
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
Funny and strange. Andrew Nesbitt has posted a far too elaborate alternate history of #activitypub
I imagine this depends on the platform to some degree, but I have an #ActivityPub question: Is the home timeline chronological on post publish or when your instance becomes aware of the post?
For context, 
@postssw'as — still practising sometimes publishes a post with a publish time well in the past, for instance right now the most recent post delivered to followers (delivered just now) has a publish time which was 18 hours ago. Does this show up in your feed now, or never get seen because the feed files it away chronologically with all the other 18 hour ago posts?
This is how #Holos currently handles #E2EE DMs over #ActivityPub. Holos is a project we develop alongside #Fedilab.
It is good that there are calls to be/remain wary.
https://kevinak.se/blog/be-wary-of-bluesky
https://news.ycombinator.com/item?id=47095597
Detecting issues early, and future problems can be anticipated and prepared for. And it allows people to make informed technology decisions and weigh the pros and cons, the risks.
There are currently all kinds of typical tech ideology and protocol wars being waged, yet the answer to "Should I use this technology?" always starts with "It depends.."
I am in the #ActivityPub camp for many of the reasons mentioned in the article. At the same time I am a multi-protocol #SocialWeb proponent. Use whatever works best to satisfy needs and forms a solution.
The article also rightfully states that you are not safe from re-centralization risks and corporate capture with any protocol. Esp. not based on the protocol alone.
Did we ever honestly investigate risks to our #fediverse? What if we get big uptake, adoption, billions of fedizens? What shape will that take. Will it bring us "true social"?
Quoting from another toot I just posted:
> What I am talking about is architecture and design, and all the things that allow people to easily form a clear mental picture on how things fit together, wrap their head around the fediverse.
> Never defining this well, and having the documentation be scattered all across the fediverse in 1,001 random locations doesn't help. Meanwhile the dev talk that is going on for years remains very inefficient due to endless Babylonian speech confusion.
Another quote has steps that would then be involved with solution design, and expand fedi's interoperable apps & services:
https://social.coop/@smallcircles/116109322688804011
Without that, with app-centric protocol-decay-ensuring method we have:
0. Deteriorate your domain, reduce ambition
1. Hammer your design until it looks like a microblog, add warts for own features
2. Plug and pray that it works
3. Keep fixing based on daily fedi weather conditions
--
4. Discuss fixes in fire-and-forget fleety communication channels
To chain things together a bit on this fleety medium of ours, create a hyperweb 😜 I'll quote this toot to follow-up to
https://social.coop/@smallcircles/116110545919004233
I remember about 2018 or so, when I joined my first #SocialCG meetup. It was when the CG was still strongly tied to #SocialHub community.
There were mundane items on the agenda, interesting to any #ActivityPub dev, and also the call to action was "whether you are technical or not at all, join the meetup, we are open and inclusive to all fedizens". Very friendly, good vibes.
However during the session the talk was not only CS expert level, but dealing with subject matter nowhere near the spec. It was 'wire reality' slang, and to learn it the guidance was either nowhere, or everywhere, dispersed. And this is still as it is today. To expertised AP developers their domain language sounds all natural, but it likely seems Martian to a dev newcomer.
Stark contrast to the W3C specs that leave folks with refreshing "Let's implement this" vibe.
@reiver@mastodon.social that's a good summary for it.
@reiver@reiver ⊼ (Charles) it is a good question. It is also a question that is formulated from the perspective on how we currently see the AS/AP fediverse.
> I've seen an ongoing debate between "Note" versus "Article" in #ActivityPub / #ActivityStreams.
> When is something a "Note"‽
> When is something an "Article"‽
The question makes sense from the notion of what the current #fediverse is. It makes less sense from the context of AS/AP as described in the protocol specs.
Background to my post is this observation: https://social.coop/@smallcircles/116109447243110037
Then the answer to when is something a Note or an Article is: Always. Note is Note in ActivityStreams and Article is Article.
The question that you would be asking, if only we had a fediverse that followed the original promise of the open standards, is:
> "When is something a Note or an Article in a Microblogging domain?"
For instance.. types you have in any domain depend on your model preferences. Could be anything that serves needs of a solution.
I've seen an ongoing debate between "Note" versus "Article" in ActivityPub / ActivityStreams.
When is something a "Note"‽
When is something an "Article"‽
Personally — I would probably have made the distinction this way.
An "Article" has a title.
A "Note" doesn't have a title.
(In ActivityPub / ActivityStreams, a 'title' seems to tend to get represented in the "name" field.)
In the old blogging software I created back in the 1990s, I had a handful of posts types
There was a type of rich-text oriented post that had a title. (Article)
And, there way another type of rich-text oriented post that did not have a title. (Note)
(There were also other types of posts, but they aren't relevant here)
These 2 types of posts were rendered / displayed differently
I.e., my 1990s software already had this distinction
