Egregoros

@julian It looks simple on the surface, but in reality it is much more complicated than a non-generic server. In addition to activity transfer, generic server needs to maintain collections. First of all, a followers collection, which is often used as a delivery target. Then likes, shares etc. It needs to enforce permissions, to prevent actors on the same server from deleting each other posts.

This is doable if you only care about activities defined in ActivityPub. But then you want to introduce context collection. And then 50 other extensions. How to do that without special-casing every one of them?

This is where duck typing (FEP-2277) and unified security model (FEP-fe34) become really handy. No matter what the client sends, you can figure out what it is (an object, an actor, or a collection), and enforce permissions.

Recently, there was a discussion about generic #ActivityPub servers. Several people claimed that they were working on one, but it turned out that their "generic" servers only support activities defined in the ActivityPub specification. Such a server shouldn't be called generic. It is not difficult to build, neither it is an interesting concept because competing protocols (e.g. Nostr) already offer much more.

I've been writing a #FEP that describes how to build a real generic server. It is not finished yet, but I feel like now is a good time to publish it:

FEP-fc48: Generic ActivityPub server

This kind of server:

- Can process any object type, and can process non-standard activities like EmojiReact.
- Compatible with FEP-ae97 clients.
- Does not require JSON-LD.

I attempted to implement it when I was researching security properties of FEP-ae97 API: https://codeberg.org/silverpill/fep-ae97-server. Back then I didn't know what to do with side effects, but now I think that we can simply force clients to specify them.

Special thanks to @mariusor and @trwnh for their input.

#C2S

@phnt @i @lain @hj @sun I think you're right about FEPs and cooperation. The optimal strategy is cooperate by default and defect only when the other side defects.

With quotes we were almost successful. The initial version of Mastodon's consent-respecting quotes was based on FEP-e232, but later they decided to introduce a new property.

Now there's FEP-521a (public keys), which they expressed interest in implementing.

Even with Mastodon, it's worth trying.

>Groups

I think Lemmy's implementation is not bad. There is also Conversation Containers from Hubzillaverse, and a possibility of convergence, see this thread https://lemmy.ml/post/43519233

@steve @evan @raphael A server can't properly process an arbitrary activity without knowing its side effects. A server that only supports a small number of activities mentioned in the ActivityPub spec is obviously not generic.

I can point to other challenges because I've been working on this problem for years, but...

Several generic AP server implementations have been built
There are also simpler ways to design servers so that content isn't tied to a specific server

Wow, for real? I suppose it's time for me to retire then.

In previous years, I published two "fediverse tech roadmap" posts:

- Fediverse tech roadmap 2024
- Fediverse tech roadmap 2025

However, I didn't publish such post this year because not much has happened in 2025. Many problems I talked about require complex solutions, but unfortunately proposed solutions are often very limited or lead to centralization. Or worse, there is no solution but only an imitation of work. I don't want to write about that.

I saw a thread today where ATProto ecosystem was compared to #ActivityPub. Things are happening in the Atmosphere, but not in Fediverse. MAU graphs are flat. What's going on?

There are multiple factors at play, but I think fake activity may be the biggest contributor. Trivial developments presented as breakthroughs. Features that already exist somewhere in Fediverse presented as new inventions. Vaporware. Specs written by people who have no idea how to implement them. Working groups that do nothing but meetings.

Real work is ignored, competent developers see that and quit.

We need to fix this.

For my part, I will continue to document #Fediverse development at @weekinfediverse. But this newsletter doesn't have much impact.

@phnt

>Sticking your whole blocklist into your instance Actor is unwieldy and makes the JSON unnecessarily big.

What's the difference between sticking it into instance actor and NodeInfo doc? Both are JSON documents.

>Similarly, you can stick list of moderators/admins in there

Exposing mods/admins is a valid use of NodeInfo, because this information is important to people who are choosing an instance.

If an ActivityPub implementation needs to determine where to send e.g. Flag activity, admin/mod actors could be listed in an instance actor. Different protocols for different purposes.

@phnt

>"Intentionally skewed"

I will use it, thanks for suggestion! Yes, this requirement was inspired by GtS shenanigans.

>Do you have a valid alternative? Sticking fields into Actors is not it since those aren't instance-wide.

Sticking fields into "instance actors": https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md

>...If you need to filter data instance-wide based on software version in case of buggy behavior causing you issues/known vulnerabilities allowing breakage of trust on the network like account impersonation etc. this can be very useful when the version is correct.

You're right. I will mention this use case in the FEP.

@a

>the constituency of admins who actually host software to power their own websites or community websites is more pressing to me than fedi users in the abstract

Sure, this is important, and by "existing users" I mean all developers, server operators and regular users.

>right now i am grappling with a network that is terribly broken because i have people who can't follow me and people i can't even see from my instance, and that's without any blocks involved

Are you talking about your own implementation? I can help with debugging

>that's just weird undiagnosable software issues from a fundamentally incomplete protocol

Let's not confuse protocols and specifications. ActivityPub specification is incomplete and IMHO beyond repair.
Fediverse protocol is a different thing, it is more or less complete, and allows platforms as different as PeerTube, Lemmy and Mastodon to happily interoperate. This protocol doesn't have a specification, but I am working on it: https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md

A protocol is like language. Languages are created by people who use them, not by people who write dictionaries. Same goes for protocols, and there is probably no better illustration of this than Fediverse.

>a future where hosting a personal website is as easy or even easier than posting to social media

Isn't it already easier? A static site with an Atom feed?

In any case, I think the best way to secure this future is to build things. What have SWICG achieved since its reboot? I can name only two useful outputs: HTTP signature report and WebFinger report. The rest is pointless bikeshedding and politicking.

@phnt

One of the most annoying aspects of the ongoing corporate capture of our network is that protocol-related discussions increasingly happen on Github instead of Fediverse (or friendly platforms like SocialHub and Codeberg).

Today's example: https://github.com/swicg/groups

Why use Github to talk about federated groups when we have federated groups right here in Fediverse? That makes no sense. But some self-appointed "leads" decided to create a repo anyway.

Similar Github repos ("task forces") also exist for other protocol features. I don't see any reason to legitimize this by participating and hope that other developers will do the same.