Developer of ActivityPub-based micro-blogging and content subscription platform Mitra. I help maintain the FEP repository and write my own FEPs too. Currently working on ActivityPub Next.
I suggested the following definition for Fediverse Enhancement Proposals:
The Fediverse includes applications, services and communities using the ActivityPub protocol, its predecessors, and other historically related protocols that foster decentralized and diverse social media and culture.
https://codeberg.org/fediverse/fep/pulls/544/files
Under this definition, Hubzilla and Webfinger are parts of Fediverse.
Unfortunately, this PR was bike-shedded into oblivion.
Yes, it is known as “nomadic identity”:
https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md
If you run a small micro-blog instance, you follow some people and maybe some communities. Tagged posts come only through these follows, so you only see a tiny portion of all tagged posts.
A hashtag relay tries to aggregate tagged posts from the whole network. By following a hashtag on such relay you can see more posts on the topic that interests you.
I think it is a useful service, because it helps small instances discover content. However, this idea is not new and another service of that kind, FediBuzz, has been operating for a long time.
@robert.meyer86 See also https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md. This is already part of Fediverse and has multiple implementations.
@SorteKanin My server translates Lemmy upvotes into likes and downvotes into dislikes. That blends quite well in the UI with Mastodon’s “favorites” and Pleroma/Misskey emoji reactions, so I think Lemmy’s assumptions are correct
Identity based on a pubic key is already not theoretical, it is supported by services that implement FEP-ef61.
I am not sure whether it makes sense to separate data hosting and feed generation, this will probably require a specific network architecture, similar to Bluesky, which tends to be centralized.
I doubt that it will be implemented in Lemmy, the application architecture needs to be different in order to support cryptographic identities.
But there are other implementations (they are listed near the end of the document).
That’s correct.
did: prefix is used to denote cryptographic identifiers, in theory one could even take a did:plc identifier from Bluesky and then use it as identity for an ActivityPub application:
Yes, domain names can be replaced with cryptographic identifiers: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
DID-based identity already exists in Fediverse: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md
We currently use did:key but in theory any DID method can be used, someone even tried to use did:plc: https://github.com/bluesky-social/atproto/pull/3943
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
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.
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.
Discourse has an ActivityPub plugin: https://discourse.org/plugins/activitypub
This plugin, for example, is enabled on SocialHub https://socialhub.activitypub.rocks/ap/about (it’s a forum for fediverse developers)