2 ms·
> using the simplest and dumb way of mapping objects in storage using their ids > https://example.com/user1/outbox/{unique-activity-id} https://example.com/use
by danpalmer 4y ago
> using the simplest and dumb way of mapping objects in storage using their ids
> https://example.com/user1/outbox/{unique-activity-id} https://example.com/user1/outbox/{unique-activity-id}
This isn't actually the simplest way, and is what makes it hard to move between software. Mastodon might use /userid/outbox/activityid, GoToSocial might use /users/<id>/posts/<id>, and so on.
The "simplest" way to do this is to treat the URLs as the ids themselves, which is what the Activity Pub spec defines. This should be the most interoperable.
- rakoo 4y agoBut it doesn't matter what each software does because the necessary endpoints are defined in your actor object linked from your webfinger entry. That's the only endpoints the user agent is supposed to see and use. Now if you're saying the ActivityPub spec is tragically underdeveloped, sometimes on purpose it seems, and doesn't define actually useful stuff but leaves it "to the particularities of implementations" then I fully agree with you
- danpalmer 4y agoMaybe true with endpoints in the actor object, but clients should be able to refresh any object from its URI at any time, I believe this is a spec requirement rather than just advised, although I could be wrong. As for Activity Pub lacking clarity, I do completely agree, it's going to be years before we have a good understanding of what the spec actually necessitates in production implementations.
- rakoo 4y agoThis would be "interoperable" in that it's easy to go from one framework/software to the other, but it's still not transparent. The current way of doing things is to use the url of the object in the search bar, and thus use the search bar as the "new" url bar. In practice it is more interoperable because all softwares then behave the same.