

I mean event kinds: https://github.com/nostr-protocol/nips?tab=readme-ov-file#event-kinds
ActivityPub has Note and Follow, Nostr has 1 and 3.
Developer of ActivityPub-based micro-blogging and content subscription platform Mitra. Working on Fediverse standards: https://codeberg.org/silverpill/feps


I mean event kinds: https://github.com/nostr-protocol/nips?tab=readme-ov-file#event-kinds
ActivityPub has Note and Follow, Nostr has 1 and 3.


I don’t know much about recent developments, but the early version of the protocol had several major flaws:
- Identity is based on a non-rotatable key, other types of identity are not supported.
- No privacy without encryption.
- Media attachments are not supported, all images are stored on a single server.
- Servers only store data and don’t do anything else, so they get abstracted away and everyone uses the same 5 relays (in Fediverse each server has a personality, and that creates a strong incentive to self-host).
There are also many minor things that I dislike, for example the use of numbers instead of human-readable names, unusual cryptography and so on.
By separating core protocol requirements and optional features.
The guide has a section titled “Protocol features”:
This is a place where information about optional features is collected, and soft deletion FEP could be mentioned there. A formal specification could be structured in a similar way.
>Currently it’s hard to read, there is no single document. No single source of truth.
We can make it happen.
I am currently working on this: https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md. It’s a guide for developers, but in the future it may be used as a base for a more formal specification.
Sucks, right, because on the theadiverse, you’re not actually able to do that so easily.
Sounds like an unnecessary limitation of threadiverse software. Why limit a post to only one community? That doesn’t make any sense.
The person who made the post with multiple mentions clearly did it intentionally, and I would do the same because for every topic I am interested in there are 4-5 groups on different servers.
Every mentioned person gets addressed
In most cases, this is what a user wants. Some platforms support silent mentions, though (Friendica, if I remember correctly).
hashtag / community tag soup
I think this should be viewed as a moderation problem, not a protocol problem. If you don’t want to see mention soup, just limit the number of mentions per post on your instance.


It federates, I was told that it uses FEP-1b12. However, I haven’t yet gotten past the actor discovery because there is always some bug that prevents further interactions 😅


If the goal is normie-friendly social media with full ownership, it would be better to work on peer-to-peer Fediverse applications.
You can get to a point where you just install an app on your phone and it’s yours forever. The foundation for this is already being built: https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md
Self-hosting is nice but it requires an always-online, publicly accessible server and a domain name.


ActivityPub messages are not encrypted, but they could be signed. Signing doesn’t prevent edits and deletes.
Yes, if someone has unsubscribed they are unlikely to be notified about the deletion.


As I understand it ActivityPub uses a combination of push notifications at time of publishing and pull notifications at time of subscription/query for objects?
It’s a mix of pushing and pulling. When something happens, the server pushes a notification (“activity”) to other servers. But recipients often need to pull additional data, such as user profiles or related posts.
Duration of caching is set by the instance admin I take it?
Yes, and it also depends on the software. Some applications may keep cached objects forever and only prune cached media (because objects don’t require much space).
Regarding Authorship, if there wasn’t an issue then ATProtocol devs wouldn’t have made it the cornerstone feature of their network
Moving in ActivityPub world is difficult because authorship is tied to a specific server. We can solve this problem by using cryptographic identities and signing everything, like ATProto and Nostr do.
I’d like to know how delete requests propagate, when the “Object” is deleted does a request to clear cache go out to all federating instances?
Deletes and edits are usually sent to followers of a user or a community. Delivering them to all known instances is not practical.


The main advantage is efficiency. You don’t need to poll 1000 servers every minute to get fresh content because everything is delivered straight to your inbox.
the cost of broad redundancy of content and authorship issues
ActivityPub doesn’t have redundancy or authorship issues. An object only exists on the originating sever, other servers merely cache it. This is not different from what RSS readers do, for example.


I think Solid had some interesting ideas, but was ruined by Linked Data.
ActivityPub has a chance of evolving into something like Solid, but better.
Actually, I am already using a single account for interacting with most Fediverse apps. Aren’t you on Mbin? I thought it also can interact with blogs, forums and everything in between


I would like to use a single account for everything, rather than separate accounts for different kinds of content. A server that works like super-app.


I don’t like the idea, but at least one such application is already being developed:


FEP-ef61: Portable Objects describes how to use DIDs with ActivityPub. Here’s a slightly less technical introduction: https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md
It’s not easy, though. Adding this feature to an existing project will require a lot of work, especially if you don’t want to share signing keys with servers. This was discussed in #3100, Lemmy devs are not opposed to FEP-ef61, but they don’t plan to work on it.
Also, I don’t recommend copying solutions from ATProto, their did:plc and did:web are not really “decentralized”.
Mastodon enforces character limit for its own posts, but not for posts coming through federation. Most Fediverse platforms work in the same way, so differing character limits is not a problem.
I don’t know about Bluesky, it may truncate long posts because it uses a different protocol.
ActivityPub is supposed to be a solution to this problem.
As far as I know, Mastodon and Pixelfed are already interoperable, and shouldn’t need a cross poster. Bluesky users can be reached through BridgyFed. Lemmy is only partially interoperable with Mastodon, but this is a result of developers’ choices and not a limitation of the protocol. I can post to all four services, for example.


Fediverse is tens of thousands of instances. You may need a VPN to access your home instance (e.g. if it is blocked in your country), the rest of the network can be accessed from there.
I never heard about instances doing KYC (which is usually done by payments processors). If your home instance requires KYC, you can always move to another instance that doesn’t require it, because there are so many of them all across the world.
VPNs are not much different from the Fediverse, by the way. It’s just servers, they can be blocked by ISPs, and they can geoblock users. This is also true for Nostr relays, IPFS gateways, Tor relays, etc.


Fediverse is very good at censorship resistance, much better than alternatives.
If internet is restricted in your country, use a VPN. If you’re an admin, move your server to a different country.
If internet is not restricted, then there is nothing to worry about.


One of Mitra users made a video about subs long time ago, I can’t find it now. You’re right, I should make a video too (and also a website etc etc).
But I need to finish nomadic identity first, as it is the main objective of the project.
Yes, it is feasible and such instances already exist.
For example, you can run a Mitra instance on Tor, I2P or Yggdrasil. It is a lightweight micro-blogging server similar to Mastodon:
https://codeberg.org/silverpill/mitra
Tor / I2P docs:
- https://codeberg.org/silverpill/mitra/src/branch/main/docs/onion.md
- https://codeberg.org/silverpill/mitra/src/branch/main/docs/i2p.md