One (small) issue is that it assumes there *is* a client outside of the server. Most server apps have both a web UI and an API, and it's even possible to build an ActivityPub server with no client API at all (microblog.pub was like that, IIRC). I think the ActivityPub C2S API was intended for servers that worked just like you're describing, but IDK if anyone ever really implemented it properly.
this post was submitted on 15 Nov 2024
1 points (100.0% liked)
Fediverse
29172 readers
2462 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 2 years ago
MODERATORS
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.
There have been some platforms that combined form factors like Friendica and mbin
Mbin is so cool, it's what I'm using.
While I think fragmentation can grow into being a problem, trying to standardize things too much can be problematic too, as the developers would be bloating the software for features that the community may use very little, as well as, by consequence of the bloating, the devs being either limited to a design that needs to take into account the quirks of all object formats, or to make some frankenstein monster design to include those different formats.
A more reliable path, I think, is what Kbin (RIP) and its successor Mbin do, to have a section for articles and one for notes. While it's still more load on the developers and the servers, at least it shouldn't be as much as having to make sense of multiple formats together, since the two sections don't directly interfere with each other. This, on a final point, is, to my understanding, and with their respective proportions, what happens with the Linux family of operating systems, where it's also pretty fragmented, but every once in a while a way to put two different environments together appear, like Wine and Xfce translating Windows and QT5 programs, or AppImage and Flatpak trying to be as universal as possible by depending on as little default dependencies from the host system as possible.
I haven't developed anything with #ActivityPub, but have read a little bit of the spec. I would love to hear the take from developers making use of it.
(Sorry for the mention in any case)
No. The various Fediverse server applications are too different in how they work.
First of all, it isn't all just about object types. The architecture of various Fediverse server applications is vastly different, including how they handle objects, and how they distribute them.
For example, on Mastodon, a thread is just a loose string of posts and more posts which, technically, are identical in properties. Mastodon doesn't know conversations, and Mastodon doesn't know groups. You receive the posts from those whom you follow plus, by default, the posts that mention you.
Friendica does know conversations, and it knows groups because it has them implemented. On Friendica, a thread is one (1) post plus comments, just like on Facebook or on blogs. You receive the posts from those whom you're connected with, but not their comments on other people's posts. Plus, you receive all comments on posts from those whom you're connected with. Receiving posts from those whom you've mentioned is optional but off by default AFAIK.
Forte is like Friendica, but with nomadic identity. That obviously isn't a client thing.
Hubzilla and (streams) are like Forte, but with wholly different protocols that were made for nomadic identity in the first place and with ActivityPub as an optional extra.
Lemmy, Mbin and PieFed are all about conversations and groups. You literally can't follow Lemmy users (something that Mastodon users will never understand), you can only follow Lemmy communities (something that's totally alien to many Mastodon users).
There are many more differences.
Mastodon's HTML sanitiser that rips out most text formatting is on the server side AFAIK. If you make Mastodon the gold standard, say buh-bye to numbered lists, horizontal lines, tables etc. (And I'm not kidding, there are places in the Fediverse that support these. In posts.)
Character limits are server-side. Since the huge majority of Fediverse users and many Fediverse devs think the Fediverse was made as a Twitter replacement, they also think that there has to be an arbitrary character limit, otherwise it wouldn't be microblogging, right? Welll, then Friendica, Hubzilla, (streams) and Nomad can wave good-bye to their unlimited character counts and 100,000+-character posts.
Filters are server-side. And they work vastly differently on different Fediverse server apps. Some import filtered content and then delete it. Others reject it.
Permissions are server-side. Permissions are absolutely essential and integral parts of Hubzilla, (streams) and Forte, but the entire rest of the Fediverse doesn't even know they exist. Of course, it'd be great if everything down to mastodon.social implemented the (streams)/Forte permissions system, but it'd completely overwhelm those who came to mastodon.social in search of Twitter without Musk.
Another feature that Friendica and Hubzilla could kiss good-bye if there was only one unified server backend are multiple profiles per account. Speaking of which, it's farewell to multiple channels (identities, like accounts everywhere else) on one account/login for Hubzilla, (streams) and Forte. Unless everything else is willing to implement both.
Lastly, Hubzilla has absolute literal shit-tons of features on top of even Friendica. Both have built-in file spaces, but Hubzilla has one with WebDAV connectivity (as do (streams) and Forte). Both have federated event calendars, but Hubzilla also uses it as a frontend for its built-in CalDAV calendar server (which is headless on (streams) and Forte). Hubzilla, (streams) and Forte have an optional CardDAV addressbook server. Hubzilla also has optional stuff like non-federating long-form articles, "cards" that work similarly, a simple built-in wiki engine for multiple wikis per channel with multiple pages each, support for simple webpages (the official Hubzilla website is on a Hubzilla channel) and so forth. I'm not even remotely kidding with any of this.
If you want to unify Fediverse servers, they'd all have to become Hubzilla, but with nomadic ActivityPub.
Imho, ActivityPub is a bad protocol that tries to accomplish everything, and ends up being bad at all of it. The spec is also ambiguous in a lot of areas. And major implementations don’t always follow the spec. All in all, it’s a miracle the fediverse even works as well as it does.
Instead of being "bad," I consider ActivityPub as not being mature yet.
Other internet protocol like HTTP or email are also really basic on its early inception, but it later adding so many features and capabilities to be more modern and flexible.
Give it enough time, and ActivityPub will be mature enough for varied use cases.
I didn’t say basic. I said bad. HTTP 1 is a good protocol. ActivityPub is not. Read both the specs if you don’t believe me. I have.
There’s not a single point in HTTP 1 that I thought, “what the fuck does that mean?” There are several in ActivityPub. ActivityPub also has several areas that are ambiguous. Ambiguity is bad in a specification.
ActivityPub tries to support everything, and has no defined behavior for when a client doesn’t support whatever thing it just received.
It also uses JSON-LD, which isn’t necessarily bad, but defeats the purpose of JSON by making it too complicated to easily write by hand.
This is not easy to write, read, or parse, or build:
{
"@context": {
"name": "http://xmlns.com/foaf/0.1/name",
"homepage": {
"@id": "http://xmlns.com/foaf/0.1/workplaceHomepage",
"@type": "@id"
},
"Person": "http://xmlns.com/foaf/0.1/Person"
},
"@id": "https://me.example.com",
"@type": "Person",
"name": "John Smith",
"homepage": "https://www.example.com/"
}