Another example of the need for careful terminology use is in the post that @silverpill quoted above:
> prevent actors on the same server from deleting each other posts
"post"? There is no post in #ActivityPub, not as a verb and neither as a noun. While I am not worried that silverpill used the word in a wrong meaning here, the terminology easily leads to confusion where someone who interprets AS/AP to be equivalent to the fediverse we have today, pictures in their mind as Mastodon posts or toots in fedi slang, or elsewhere called statuses.
That is app terminology. AP only knows Actor, Activities, Objects, and perhaps Collections. Period. The rest is solution design.
Where they are transferred they can be said to be messages, and messaging happens.
@raphael @silverpill @julian @mariusor
I agree. Aboveall we need to know where protocol ends and 'app' begins. And be generally more deliberate in terminology use, and no longer talk in overloaded that has different unclear meanings to different people in different settings (to avoid saying 'contexts' one of such overloaded words :)
I've noticed for instance people having a very different notion of what a 'generic server' is, in definitions that are almost diametrical opposites.
My definition of generic is 'not specific' i.e. a generic server is a pure #ActivityPub protocol implementation (which is something to agree upon, what that exactly entails), having no knowledge of *any* app / solution built on top of it or 'passing through' its messaging architecture.
In the other meaning a generic server 'knows/does/has it all' i.e. it understands everything we comprise to be 'the fediverse' in a kind of hard-wired fashion based on the functionalities that (marginally) interoperate today.
did a little server migration with everybody's buddy claude and everything lives on! dang if he doesn't know what he's doing. not that i did anything complicated whatsoever. #mitra #activitypub #decentralization
NodeBB v4.9.0 — A Whole New /world!
Hello all!
(Sorry, I could not resist with the title
)
Today we are releasing NodeBB v4.9.0, on a Friday, toward the end of the day, because we like having our weekends ruined.
As usual, we recommend you update to this stable version of NodeBB, not least because it fixes a federation issue accidentally introduced last month.
There are a bunch of new features and usability improvements here, for both end users and admins. Federation improvements abound, as well as a few moderation upgrades. As usual, we fixed a ton of bugs, and even a couple open issues from the 2010s ![]()
Here is a list of the changes and new features you should expect to see! [...]
https://community.nodebb.org/post/106679

@soundsbeard Interesting. I have no idea how the #ActivityPub system works, but on YT people also complain a lot about not getting notifications for channels they are subscribed to :D
I wish I could use IndiePass to connect to my Fedify/Indiekit ActivityPub server so to have a unified publishing/reading experience for both Indieweb and ActivityPub
right now I have this but only on the browser
🔗 https://rmendes.net/notes/2026/02/27/624ea
@freedomofpress lastly by using these platforms that are on the #fediverse and utilize #activitypub people can follow your channels directly from #mastodon like/comment etc ... something these closed platforms can't and won't do.
an interesting thread on Bluesky about why people are choosing to build on #ATProto instead of #ActivityPub
https://witchsky.app/profile/did:plc:rtf3bjc3w2yn4syxtm4r7jt2/post/3mfrp6tovy22g
Has anybody thought about modelling #activitypub with a tool like https://alloytools.org/book.html
to find potential exploits? Thinking about the spec it’s missing any algorithms for authorization, but I already found a couple of edge-cases that make a server DoSssable or give an attacker the ability to spoof messages …
@elvecio è quello di cui si è sempre lamentato Macgirvin; del resto se nessuno ti caga, anzi, ti evita, le tue proposte possono pure essere interessantissime, ma si impantanano... un po' come #solid di Sir Tim Berners-Lee
#nostr invece è una fogna, ma è splendidamente funzionante in tutto, persino nel ponte con #activitypub (è che se poi le istanze bloccano lo fanno su tutto il flusso dell' utenza che sfrutta quel ponte... dettagli di censura generalista e non selettiva)
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.