Behavior spec: Remove the "Create flow" (#155)
So far there have been 2 ways to ask to create an object on another
server:
- The Offer flow, which means the receiving side will be hosting the
object. This means e.g. repos would be hosting their tickets, on the
same server. This is the easy and obvious option.
- The Create flow, which means the author hosts the object, and the
receiving side will just remember its ID, but the receiving side is
also the one responsible for specifying access control.
The Create flow has existed because of the deeper distribution is
allows, where objects and their child objects can live on different
servers. It also allows users to host their own tickets, much like they
host their own comments and messages. But it's a challenge because
actors can't entirely reliably enforce access rules and integrity rules
on child objects hosted elsewhere. Having 2 flows also adds complexity
to implementations.
After a lot of thinking, I decided I wish to remove the Create flow. It's a
huge simplification to the specification and to implementations. The
mitigation for losing the advantages of the Create flow is:
- The kind of decentralization on the Fediverse isn't a fully
distributed situation, and in particular it doesn't help with remotely
enforcing access control. If/when the fediverse goes fully P2P, it
will surely have such mechanisms. I believe actor-level decentralization is
*definitely* enough to solve the problems of centralization that we have with repo hosting websites. It's also
probably the best that's reasonably available to us without resorting
to p2p and cryptography based solutions.
- If people want to host their own tickets, then can create a personal
ticket tracker and use it as their to-do list or as a place to list
bugs that got rejected by the relevant projects, or whatever people
want to use personal tickets for
- Actor-level decentralization is simple, clear, easy and elegant, and I don't
believe we really need anything more complicated
I implemented the Create flow on Vervis. It added huge complexity. I'm now busy removing it, suffering the complexity of removing all that stuff entangled in my code... :P and seeing how much simpler things were before I implemented it "^\_^
Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: https://codeberg.org/ForgeFed/ForgeFed/pulls/155
Reviewed-by: Anthony Wang <ta180m@noreply.codeberg.org>
Co-authored-by: fr33domlover <fr33domlover@noreply.codeberg.org>
Co-committed-by: fr33domlover <fr33domlover@noreply.codeberg.org>