This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will block this actor and hide all of their past and future posts. Are you certain you want to block this actor?
This action will block this object. Are you certain you want to block this object?
i don't know about this decision:
It is suggested that LitePub implementations supply a locally hosted version of the LitePub JSON-LD Context as their @context.
what i see in practice (N > 100) is the same "litepub-0.1.jsonld" context but different URLs. all of these identical contexts have to be fetched, parsed, cached (hopefully).
it seems wasteful.
i've tested ktistec compatibility with:
many things work—follows in both directions and creating/updating notes (AKA toots, etc.)—but there's lots of room for improvement. lemmy, for example, announces activities instead of forwards activities. i'm working on 1.0, but in the next major release, i'll build server-specific extensions to handle more of these kind of issues.
i created a few issues in other repos:
and worked around a few issues that haven't quite rolled out:
and made many other concessions for compatibility.
once you've seen one activitypub implementation, you've seen one activitypub implementation.
i just wrapped up a whole lot of interoperability work for ktistec. bottom line, you can't just read and implement the activitypub spec et al and expect anything to federate with your implementation. your best bet, in fact, is to doggedly copy the mastodon implementation, right down to the braces and brackets—since every other implementation is at least shooting for mastodon compatibility—and then work from there.
to be fair, about half of the fixes were arguably due to bugs in my own code. but seriously lemmy, why do you require the json-ld context to be a list, even when the context is defined by a single URL...?
one criticism of activitypub is that it's not a specification, and as a consequence you have to test extensively to ensure interoperability between implementations.
this is a valid criticism.
to some degree i guess i don't care. i'm building a free/open source application not a commercial product, and it's aimed at relatively tech-savvy users, and i kind of enjoy spelunking issues like these anyway, but for anyone whose goal is mass adoption of the "fediverse" concept, it's a problem.