A custom signed type that respects ACL and identity for y.js

[fritzy]

I'm starting a new y.js data-type to serve an eventual Blog Platform DApp. The original idea was to make a y.js type that had built in ACL and signing. For the past few days, I've been experimenting with this.

The only documentation for doing this is very out-of-date, so I've been pouring through code. It now looks like the easiest thing might be to modify the map type.

The needs:

• signed data to ensure authority
• respect of ACL
• easy and fast API for developers

y-signed-table would be a modification of the Map type with a few additions:

• require a signature on all map changes
• refer to an ACL map (or signed-table) for authorizations for how a user (given their signature) could change things
• only allow a depth of 2 (and no other types)
• no-op on any operation violating ACL, signatures, type definition, etc
• storage of extra indexes for filtering/sorting beyond primary id
• query helper functions

The ACL table can be another y-signed-table that only accepts admin flagged users.

There may be a need for a special type for managing the user identities and all of their public keys, but we can cross that bridge later

Later on, it'd be nice if y.js supported ways to maintain and prune the CRDT log -- snapshotting, pruning no-op, pruning logs about objects that have since been deleted, etc.

OR, I could use https://github.com/ipfs-shipyard/peer-crdt. It'd take me awhile to build something on top of it that exposed something nice to front-end developers, I think. In the meantime, I've been working on the y.js custom type.

[fritzy]

The goal is to only sync metadata, and to generally refer to IPFS file URIs for content. The y.js or peer-crdt types would only be used to define relationships and references to file objects.

I'm wondering if @pgte and @dmonad have thoughts on this approach.

[fritzy]

After working with modifying y-map, it looks like I'd have to modify how operations were handled in y.js in order to sign delete operations (inserts are fine, because I can just sign the contents). I'm going to work with peer-crdt, as it already seems to have signing.

@pgte in peer-crdt, if a node relays an operation that it did not author, does it re-sign the operation, or is the original signature intact? Ideally the original signature is used and the operation is relayed, unmodified and signed by the original author.

[pgte]

@fritzy in peer-crdt an operation can be signed and encrypted before it's stored in IPFS, which means that the operation can be relayed without modification by any node (using the IPFS DAG API).

[fritzy]

@pgte do you have time for a 45 minute call for me to pick your brain this week? I'm working on getting a js dapp going this month. If you don't have time, I can keep posting questions and plans selling comments here.

I was planning to use js-ipfs pubsub to distribute the crdt based on topic discovery of app structured metadata, with Uris to ipfs files for content. The js-ipfs nodes are fairly ephemeral, so I'm not sure the ipfs dag is the right way to go.

[fritzy]

More accurately I need to put up the basic scaffolding for a dapp this week.

[fritzy]

I'll make an experiment, using https://github.com/ipfs-shipyard/peer-crdt-ipfs and to see if each peer validates the same signature. Thanks @pgte

[pgte]

@fritzy yes, sure, tell me 2 or 3 time slots that suit you and I'll try to fit in :)

[fritzy]

@pgte Today (March 5) at 1pm PST (9pm GMT), tomorrow (March 6) at 9am PST (5pm GMT) or either of those times on the 7th. If need be, I can do 6am PST tomorrow March 6 (2pm GMT)

[pgte]

@fritzy 7th 5pm GMT works for me.

…

On 5 Mar 2018, 16:52 +0000, Nathan Fritz ***@***.***>, wrote: @pgte Today (March 5) at 1pm PST (9pm GMT), tomorrow (March 6) at 9am PST (5pm GMT) or either of those times on the 7th. If need be, I can do 6am PST tomorrow March 6 (2pm GMT) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[JonKrone]

Have you made progress on these awesome ideas @fritzy?

I've been thinking about a file store + share dapp: peer-base/peer-star#1 this week and came to many of the same conclusions regarding encryption, acls, distribution over pubsub, and relying on the crdt structure to hold metadata but uris for content. Great to read this and find that our thoughts converged.

I'm curious about a point I don't follow from your OP: only allow a depth of 2 (and no other types). Why restrict the depth? Also, I was considering something like a signed-map that could be composed of other signed-* types. In my case, content referenced in an object may have stricter access controls than the container. Was your reasoning that a nested type could not handle its container's encryption?

Cheers :)

[fritzy]

@JonKrone So, instead of doing this at the type level, we're implementing sign, verify, and validate hook methods that can be used for any peer-crdt type.

The single-depth stuff was to produce a table like model-collection type, but that's very separate from the goals of validating authorship, and may or may not apply to permissions.

You can see an example of this in ipfs-shipyard/peer-crdt-platform. I'm breaking it up more into an identity package and an acl package.