Understanding ActivityPub and Federation
I have tried to understand how Federation works but I’m getting a feeling that there’s some rather large gaps here. My first attempt was to find an API implementation in python, 3 wasted hours of my life later and I’m making requests.request() calls like it’s 2007. And I still can’t access the content as presented on the webinterfaces. There doesn’t seem to be a way to access eg the communities tab via activitypub? Any Help?
There doesn’t seem to be a way to access eg the communities tab via activitypub? Any Help?
If you’re writing client-to-server part (not server-to-server part), try
curl 'https://<lemmy-instance>/api/v3/community/list?sort=Hot', and an API client libraries written in Python..Hi, I’m well aware of those APIs, but the idea was to find a unified way using ActivityPub. As it stands AP seems to actually have this glaring omission at its core. I’m somewhat baffled how this skipped past so many interations. What you mentioned is certainly a valid option to access data on lemmy. But it won’t work on Mastodon, or any other service only linked via ActivityPub Federation. And that’s a problem. It splits the network apart at the seams.
I’m not an expert, but based on my understanding the Communities tab (as well as things like your user profile) are special to Lemmy, and stored on a given Lemmy instance. ActivityPub basically provides a shared language for how various services/clients can ask for and send each other data (posts, comments etc) in a totally agnostic format. Lemmy renders this data as posts and comments, but Mastodon renders them as toots and so forth. And that’s an oversimplification, because there’s no guarantee that two pieces of software (Lemmy and Mastodon in this example) will operate with the same ActivityPub types, so the way content is displayed is inconsistent or possibly entirely incompatible. If you want to create a generic Fediverse reader, you would need to keep an up-to-date representation of every type that every common ActivityPub software uses for its content, which could work but I imagine would be quite tedious and prone to breaking. That being said, I was imagining something like this existing myself, and I suspect over time as different types become common “building blocks” for different types of social networks this will be more solidified and straightforward.
To your mention of content not being accessible from everywhere, it sounds like maybe you’re expecting a centralized directory of information, but that’s the big difference with true decentralization/federation. No single Lemmy instance know of every other Lemmy instance, they only know the ones they’ve talked to. All of the data is accessible if I know the hostname of a Lemmy instance, I just need to know the hostname first, and unless we build a centralized repository of every instance, we will never know of every single one. In the meantime, larger Lemmy instances have a large enough list of federated servers to get you most of the way there in terms of a directory, so maybe that’s a reasonable stopgap.
You actually described my expectation in that last paragraph. I fully expected to have to invent a curated list of endpoints. What I instead found was that even given an endpoint (like beehaw.org) there is no way to discover what is on that instance. Which is a big issue. I’ve discussed this a bit (albeit extremely slowly) with the folks in the activitypub irc, and pretty much got it confirmed. If you want to develop a service that is intent on delivering any form of public content at all, supporting activitypub, then you have no protocol based way of communicating this content to anyone. So going by that the lemmy implementation is actually “correct”, in as much as the protocol simply fails to provide guidance for this critical step.
ActivityPub is what instances use to talk to each other, not what the web interface uses. So the way Communities are propagated over the ActivityPub depends on what lemmy does, not what ActivityPub wants. Are you trying to develop your own instance or are you trying to make a 3rd party UI for lemmy?
@Hexorg I’ve begun yesterday with the question “why can’t I access information without first having to know where it is?” I’ve now basically gone through confusion, anger, disbelieve and now acceptance that there really is nothing to find. In the end the concept of federation says that stuff should be accessible from anywhere. But it isn’t. Which is a pretty big problem imo.
My goal is to indeed create a generic fediverse reader, not using any specific platform APIs.I’m working on something similar in swift and started my project with the assumption that I’ll need different API classes for every type of “instance” I want to gather data from (mastadon, lemmy, kbin, etc) and custom server model objects for each instance (as while some properties might be standard across all instances there will probably be some that are specific to an instance(s)).
Then I’ll need those objects to be wrapped in a unified protocol to access and display them. Certainly not ideal, and does seem counterintuitive to the idea of the fedi-verse; but hopefully something for activity pub to work towards.
@evilviper I’ve actually gone ahead and begun work despite lack of discovery. https://github.com/JustusW/UnifiedFediverseObserver
Early stages, but I already can go through linked relations in many cases.
