Role-based thread access control

[sanderpick]

The current model based on thread type and sharing settings is over-engineered and confusing. This design was largely based on the idea of an immutable member "whitelist". Only the addresses in the whitelist are allowed to join, ever. This is a little superficial though in a way… and is the reason for the current complexity.

Roll-based access, like that seen in Google Docs, etc. is much more familiar to internet users. Something like this graph (thanks to @leshokunin):

In practice, this means throwing out Type and Sharing, and re-purposing Members. When creating a thread, you’d just need to define the “star” (*) member’s roll (admin, write, view+comment, view, or no access). The assumption here is that an admin/owner can invite others, no matter what.

We should consider another capability around "view history". The thread purpose dictates whether or not new members ought to have the ability to view history or not. For example, most would agree a chat thread should not grant view history, but a photo album should. However, unless we leveraged the double-racket algorithm., not sure how this could truly be enforced.

Questions:

Is there a place for voting to ban or remove content? Banning will have to come from key rotation. Essentially, we'd have to enable thread forking... plant the old key in the chain for backward traversal, and then use a new key going forward.

[leshokunin]

How about having the voting in the comment thread?

…

On Wed, Apr 17, 2019 at 17:18 Sander Pick ***@***.***> wrote: The current model based on thread type and sharing settings is over-engineered and confusing. This design was largely based on the idea of an immutable member "whitelist". Only the addresses in the whitelist are allowed to join, *ever*. This is a little superficial though in a way… and is the reason for the current complexity. Roll-based access, like that seen in Google Docs, etc. is much more familiar to internet users. Something like this graph (thanks to @leshokunin <https://github.com/leshokunin>): [image: image (1).png] <https://camo.githubusercontent.com/9c10f9a949dbc2048618ce50aeec614c89eb1ef1/68747470733a2f2f696d616765732e7a656e68756275736572636f6e74656e742e636f6d2f3563326538373961346665623438323963303133353330632f36346339353332352d323333652d343836312d623362332d336233396237653036616630> In practice, this means throwing out Type and Sharing, and re-purposing Members. When creating a thread, you’d just need to define the “star” (*) member’s roll (admin, write, view+comment, view, or no access). The assumption here is that an admin/owner can invite others, no matter what. We should consider another capability around "view history". The thread purpose dictates whether or not new members ought to have the ability to view history or not. For example, most would agree a chat thread should not grant view history, but a photo album should. However, unless we leveraged the double-racket algorithm., not sure how this could truly be enforced. Questions: Is there a place for voting to ban or remove content? Banning will have to come from key rotation. Essentially, everyone agrees to leave start using new key. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#694>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHMD5CHBOS3TOWKUZZKUI3LPQ647HANCNFSM4HGYYR4A> .

[sanderpick]

Seems like you'd want to do something like "propose" an action that could be voted on with an additional block type... that could look very much like a comment, but carries an explicit meaning.

[sanderpick]

(Also, apologies for the delay in getting this issue written up!)

[leshokunin]

Agreed. I think the thread is a good place for those things. One thing in the Epona designs I've been considering is having the ability to react to things. For example replying to a comment, or liking a comment. I would imaging voting would be similar.

[sanderpick]

Yep, exactly. You can currently "annotate" (like / comment) any other block type.

[leshokunin]

So you can like a comment?

…

On Wed, Apr 17, 2019, at 20:02, Sander Pick wrote: Yep, exactly. You *can* currently "annotate" (like / comment) any other block type. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#694 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHMD5CHOW2H4FMJJW5FKS73PQ7QFHANCNFSM4HGYYR4A>.

[carsonfarmer]

Yessir! Like, comment, and we have the ability to ‘flag’ something. Though that API isn’t fully exposed yet. But comments and likes are.

[sanderpick]

From a convo with @andrewxhill this morning, let's think deeper around how to include apps in this framework beyond the current unique thread key string.

[leshokunin]

That would be great. What kind of issues do you have in mind? I’d love to make sure I can access the same things from all my devices and perform the same actions with the same account.

…

On Mon, Apr 22, 2019 at 10:03 Sander Pick ***@***.***> wrote: From a convo with @andrewxhill <https://github.com/andrewxhill> this morning, let's think deeper around how to include apps in this framework beyond the current unique thread key string. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#694 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHMD5CGHRHJEBYXN4GXZRH3PRXVWLANCNFSM4HGYYR4A> .

[andrewxhill]

illustrative use-case I had in mind:

Someone tweeted that they wanted photo support in Notes app. One way to do that would be to create a second Media thread in the Notes App. That Media thread should also be permissioned to the Photos app… so your Photos notes are part of your unified galleries in a way. Up to the user to do that permissioning, but once they do, both apps would have access to the single thread.

Not that we will do this, it's just a nice clean example.

[leshokunin]

I’d “nope” out real fast of a system like this. Sounds like I’d be limited from building custom things on top of Textile, and would be beholden to some standard. I’d think of my apps as just clients, renderers for that content. It sounds really heavy handed to me. I’d prefer if there was a general API for actions on items, so if someone wanted to query Notes from the Photo app, they could, so long as they auth properly and prose the content the way it was done (assuming the people who did the notes and photos apps documented how they do it).

…

On Mon, Apr 22, 2019 at 10:07 Andrew W. Hill ***@***.***> wrote: illustrative use-case I had in mind: Someone tweeted that they wanted photo support in Notes app. One way to do that would be to create a second Media thread in the Notes App. That Media thread should also be permissioned to the Photos app… so your Photos notes are part of your unified galleries in a way. Up to the user to do that permissioning, but once they do, both apps would have access to the single thread. Not that we will do this, it's just a nice clean example. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#694 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHMD5CBNLYKF2H5VVPYI623PRXWF7ANCNFSM4HGYYR4A> .

[andrewxhill]

I think you are reading it wrong. It's in-line with your second thought.

[leshokunin]

Great!

…

On Mon, Apr 22, 2019 at 10:21 Andrew W. Hill ***@***.***> wrote: I think you are reading it wrong. It's in-line with your second thought. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#694 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHMD5CA6Y7EED2VTH5SVOKLPRXXZ3ANCNFSM4HGYYR4A> .