Fediverse

28396 readers

238 users here now

A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).

If you wanted to get help with moderating your own community then head over to [email protected]!

Rules

Posts must be on topic.
Be respectful of others.
Cite the sources used for graphs and other statistics.
Follow the general Lemmy.world rules.

Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy

founded 1 year ago

MODERATORS

[email protected]

Shouldn't all ActivityPub servers implement all objects and leave it to the client? (fedia.io)

submitted 2 days ago by [email protected] to c/[email protected]

19 comments fedilink hide all child comments

Wouldn't that be better? Let me see if I can explain what I mean. Here on the fediverse each server is kind of restricted to what the user can post.

@[email protected] is for notes

@[email protected] for photos (wouldn't be surprised if it used a note too)

Lemmy only for article objects.

Peertube for videos.

You get the idea.

This way of developing the #fediverse where each server only receive one kind of the objects accepted by #ActivityPub makes it more fragmented it, right? A server should send and receive all kinds of objects and should be up to the client to how to processes those objects.

If an user wants an Instagram-like app just create an account on any service and use and app with that UI, of lager they wanted to see more kinds of objects they should just use another client that supports Note, Article, etc. with the same account on the same server.

Ideally all server should have a shared API.

This fixes #fragmentation, the need to have multiple accounts if you are into multiple kinds of objects/content.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 1 day ago

Hmmm. Speaking of Fediverse interoperability, platforms other than yours (Pandacap) typically arrange things so that https://pandacap.azurewebsites.net/ was the domain, and something like https://pandacap.azurewebsites.net/users/lizard-socks was the user, but Pandacap wants to use https://pandacap.azurewebsites.net/ for both. Combined with the fact that it doesn't seem to support /.well-known/nodeinfo means that no other platform knows what software it's running.

When your actor sends something out, it uses the id https://pandacap.azurewebsites.net/, but when something tries to look that up, it returns a "Person" with a subtly different id of https://pandacap.azurewebsites.net/ (no trailing slash). So there's the potential to create the following:

https://pandacap.azurewebsites.net/ sends something out.
Instance hasn't heard of that, so looks it up, and creates a new user in its database, with the returned ID (https://pandacap.azurewebsites.net/)
https://pandacap.azurewebsites.net/ sends else something out. Instance looks in it's DB, finds nothing, so looks it up and tries to create it again. The best case is that it meets a DB uniqueness constraint, because the ID it gets back from that lookup does actually exist (so it can use that, but it was a long way around to find it). The worst case - when there's no DB uniqueness constraint -is that a 'new' user is created every time.
Repeat step 3 for every new thing you send.

If every new platform treats the Fediverse as a wheel that needs to be re-invented, then the whole project is doomed.