3 ms·

Why does the new server need to have a new url structure? Why do the URLs need a "structure" anyway? That's what TFA and OP are actually saying. Mastodon - par

Why does the new server need to have a new url structure? Why do the URLs need a "structure" anyway? That's what TFA and OP are actually saying. Mastodon - partly due to the fact that it predates federating through ActivityPub - doesn't have the concept of URL as a unique identifier for an object (in the ActivityPub sense), but uses numeric ids, or uuids in some places. If you really want "a structure", I wonder why nobody is implementing ActivityPub services[1] using the simplest and dumb way of mapping objects in storage using their ids. Ie: an actor has the ID https://example.com/user1 https://example.com/user1, therefore it's inbox/outbox should be https://example.com/user1/inbox|outbox https://example.com/user1/inbox|outbox. Then, an activity created by that user can be found at https://example.com/user1/outbox/{unique-activity-id} https://example.com/user1/outbox/{unique-activity-id}. If the activity is a Create (the only ones with a side effect of creating an object), then this object can have the id https://example.com/user1/outbox/{unique-activity-id}/object https://example.com/user1/outbox/{unique-activity-id}/object, samd. [1] My own fediverse software does this for multiple types of storage: filesystem hierarchy, k/v store, database tables, but I haven't seen anything else similar.

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 ago
  But 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 ago
    Maybe 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 ago
      This 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.

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 ago
But 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 ago
  Maybe 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 ago
    This 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.