Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Role-based thread access control #694

Open
sanderpick opened this issue Apr 18, 2019 · 13 comments

Comments

Projects
None yet
4 participants
@sanderpick
Copy link
Member

commented Apr 18, 2019

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):

image (1).png

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.

@sanderpick sanderpick added the Epic label Apr 18, 2019

@leshokunin

This comment has been minimized.

Copy link

commented Apr 18, 2019

@sanderpick

This comment has been minimized.

Copy link
Member Author

commented Apr 18, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Apr 18, 2019

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

@leshokunin

This comment has been minimized.

Copy link

commented Apr 18, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Apr 18, 2019

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

@leshokunin

This comment has been minimized.

Copy link

commented Apr 18, 2019

@carsonfarmer

This comment has been minimized.

Copy link
Member

commented Apr 18, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Apr 22, 2019

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

This comment has been minimized.

Copy link

commented Apr 22, 2019

@andrewxhill

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

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

This comment has been minimized.

Copy link

commented Apr 22, 2019

@andrewxhill

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

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

@leshokunin

This comment has been minimized.

Copy link

commented Apr 22, 2019

@sanderpick sanderpick changed the title Roll-based thread access control Role-based thread access control May 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.