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

@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.

@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

@a @phnt

Boost bots are for Mastodon. In our parts of Fediverse, we have FEP-1b12 and conversation containers, which are more powerful, and can be easily extended to support Join/Leave and roles (good topics for FEPs, by the way).

I don't think anybody who matters actually cared about W3C approval. By 2023, we had FEP process going and ecosystem leaders (Mastodon, Lemmy) were contributing. The rebooting of SWICG was absolutely unnecessary. The intentions behind this effort were quite clear from the start, but it would have lost momentum quickly if you hadn't participated, but you did and continue to do, and now these Github repos are becoming a problem.

@a @phnt I mean you personally and yes I think you dropping SWICG would have helped in 2023. Not sure about now, I don't know what you stand for.

>constituency

Do you mean the target audience? That's existing Fediverse users.

The job of any organization that maintains standards is simple:

- See what developers are doing and document it.
- Do thorough security analysis, and perform other tasks that developers may not have time for.
- Try to prevent situations where there are N different ways of doing the same thing.

SWICG fails spectacularly on all three, in fact it seems to be doing the opposite thing in every case.

>personal websites and local-first representations

This sounds like FEP-ef61 to me. I am currently working on an offline-first client.