Optional authorization model / not require explicit authorization of feeds

[hackergrrl]

It would be great if hyperdbs could replicate freely without the need of a power dynamic where the db creator has implicit control over access. We've seen in practice that this is sometimes not desirable (e.g. in cabal, where we employ a connection stream hack to auto-authorize).

[pfrazee]

I’m not convinced the “auto-add” hyperdb will actually scale, so I think it’d be smart to use the protocol extensions being discussed to test how well it works before baking it into the protocol

On Jun 1, 2018, at 8:56 PM, Stephen Whitmore notifications@github.com wrote:

It would be great if hyperdbs could replicate freely without the need of a power dynamic where the db creator has implicit control over access. We've seen in practice that this is sometimes not desirable (e.g. in cabal, where we employ a connection stream hack to auto-authorize).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pfrazee]

Copying from https://github.com/datprotocol/DEPs/pull/27:

I'm concerned about spam attacks too. Like: What happens if somebody shows up and starts dumping large datasets into it? Is there a way to stop that and remove the data they add?

[hackergrrl]

@pfrazee The argument for authorization being optional is so that each app can decide what model it wants. If I feel that I am likely to face spammers, maybe I want hyperdb's default auth model. If I'm sharing among close friends only, I may not want the hassle of managing authorizations. Or maybe I want to implement my own auth model that looks different than hyperdb's. Authorization feels very policy and not very mechanism: there are many opinions on how to do it, and one size doesn't really fit all.

[bnewbold]

This can almost be done at the hypercore layer using Feed messages to establish a new channel. Currently Feed messages have only a discoveryKey, so both peers need to know the actual public key ahead of time.

If the Feed message type was extended to have an optional publicKey field, then a peer wanting to push/propose a new hyperdb feed to be authorized could announce it that way. Could be useful in other contexts as well, achieving "push" or "submission" of multiple feeds to an aggregator.

[lukeburns]

@bnewbold one downside of that approach is it forces you to manage authorization at the connection-level. You have to connect to the authorizer to get authorized. If hyperdb were policy neutral, then you could allow replicators to freely authorize new peers.

[bnewbold]

@lukeburns I believe with my proposal above you could push to any "authorizor" to get authorized, not just the original. Presumably, with liberal authorization, almost any peer would be authorized, so making that connection shouldn't be hard (and if you're offline it doesn't matter if you are authorized). Not perfect; you might connect offline to another unauthorized peer.

Having not thought about this in some time: what if the creator of a feed wrote the secret key, or some equivalent secret material, to the feed itself? Then replicators/readers have the power to append/write. This doesn't quite work with existing multiwriter because there would be collisions on the "world-writable" feed... maybe we could have some extension where a messaged signed by an authorized secret key is sufficient? I don't see how this would all pull together, just a thought.

[lukeburns]

Oh, didn't realize that authorized members can already authorize new members. Looks like this is what cabal's stream hack is using https://github.com/cabal-club/cabal-core/blob/master/index.js#L71.

I could imagine this being tricky in cases where you do wish to limit access control, e.g. private messaging, and trust that other members cannot be added by those you authorize.