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?

Have you read through all the Lemmy API documentation?

Maybe you could dig into a few open-source clients to see how they work with it?

E.g. someone shared a basic lemmy viewer in godot the other day: https://github.com/sevonj/gdlm - it’s rough but probably not too much to read through. Was posted in /c/godot: https://programming.dev/post/48482

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..

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.