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

UX requirements for invitations #55

Open
staltz opened this issue Feb 6, 2023 · 10 comments
Open

UX requirements for invitations #55

staltz opened this issue Feb 6, 2023 · 10 comments
Labels
should Needed in production

Comments

@staltz
Copy link
Member

staltz commented Feb 6, 2023

@Powersource and I just came out of a meeting with nonlinear where we discussed requirements for the invitation system.

The invited person should be able to see some information about the group, without having to replicate actual group feeds etc.

We also need to support the inviter to revoke the invitation. So this means that instead of sending the group key (as we do now), we have to have multiple steps:

  1. Alice: Publish a DM to Bob: "grant right to invitation", containing group information
  2. Bob: Publish a DM to Alice: "accept right to invitation"
  3. Alice: Publish a DM to Bob: actual group addition msg containing the group symm key
  4. Bob: automatically detects the DM and then automatically "joins" the group, causing reindexEncrypted to run

Or when revoking:

  1. Alice: Publish a DM to Bob: "grant right to invitation", containing group information
  2. Alice: revoke the "right to invitation" such that any DM Bob publishes to "accept right to invitation" will be ignored
@staltz staltz added the should Needed in production label Feb 6, 2023
@Powersource
Copy link
Collaborator

in step 1 alice shares some information about the group to bob. alternatively points bob to the door where alice has previously advertised some information about the group.

another option could be to keep doing like we're doing now, of giving the key directly to bob, and then bob can partially replicate e.g. the member tangle to figure out the current members, and maybe some groupInfo tangle to find out the name of the group. to make this efficient we'd need tangle replication, which André said would be hard. Maybe it doesn't need to be efficient to begin with though? Although we've said we'll want group doors either way, so maybe reusing those is easiest.

@mixmix

@mixmix
Copy link
Member

mixmix commented Feb 13, 2023

I dont think we should do some multi-stage invite. I think this is all v2/later stuff.

Another thought - when we have deletes we can just use that for revocation. job done.

Remember revocation is likely rare too

@staltz
Copy link
Member Author

staltz commented Feb 13, 2023

I agree that starting simpler is better, but what part of "this is all v2" do you mean, @mixmix ? Like I'm okay doing invitation revocation later, but this requirement:

The invited person should be able to see some information about the group, without having to replicate actual group feeds etc.

Seems pretty important for storage sustainability.

@Powersource
Copy link
Collaborator

If someone has really tight storage/bandwidth requirements they would just have to implement tangle sync? :P And can always delete after having replicated it.

@mixmix
Copy link
Member

mixmix commented Feb 16, 2023

The invited person should be able to see some information about the group, without having to replicate actual group feeds etc.

EASY , we attach meta-data to the invite. If it's out of date when they finally accept, it's fine.
If the inviter lied about the group overview, there is signed evidence they are a bad actor.

It's tempting to come up with some fancy partial replication summary reduced state thing, but we just don't need to. Real world groups work based on people saying things which are true, but might only be auditable when you enter, I don't see why we need to do better than that

@mixmix
Copy link
Member

mixmix commented Feb 16, 2023

cc @staltz

@staltz
Copy link
Member Author

staltz commented Feb 16, 2023

EASY , we attach meta-data to the invite. If it's out of date when they finally accept, it's fine.
If the inviter lied about the group overview, there is signed evidence they are a bad actor.

Yes, that's fine. I brought up the lying possibility up when discussing with nonlinear, but true, we will have signed evidence that they lied.

Real world groups work based on people saying things which are true, but might only be auditable when you enter, I don't see why we need to do better than that

Interesting

@Powersource
Copy link
Collaborator

as mix said,

I dont think we should do some multi-stage invite. I think this is all v2/later stuff.

can i down-prioritize this from "Should (needed in production)"?

@staltz
Copy link
Member Author

staltz commented Apr 18, 2023

The multi-stage invite is actually one of the milestones, so it's pretty high priority (or, if you don't want to work on it now, then that milestone money won't be unlocked).

  1. Consent system for members added to groups

@Powersource
Copy link
Collaborator

Ah hmm. It just feels pretty chunky. But I guess if it'd be with so far unused money then we might be able to do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
should Needed in production
Projects
None yet
Development

No branches or pull requests

3 participants