Access control options for various Kernel apps

saintsal

Separating this thread since it’s tangential to the Convo feature itself, and is a wonderful can of worms.

@saintsal said in Convo feature - limit RSVPs to a specific audience:

I don’t think it’s a good pattern to use chatroom access as a primary ACL though. If we’re moving to wallet-based access, then I’d invert it. Either we just keep an allow list of emails, and/or use a token gate, and convo/chat access is awarded based on that.

@cryptowanderer said in Convo feature - limit RSVPs to a specific audience:

I agree about the chatroom as primary ACL being a bad pattern.

Allowlists with emails land us in the same Notion hell as before (people use this email for the RSVP, that email for slack, another for convo). I’d prefer to keep away from that.
We could gather eth addresses at RSVP and use those in various places (including and beginning with convo). No need for token gating then, unless you wanted to do it for a specific event that you only want close friends at. Then, you could even charge for those tokens, send people the fee back if they attend, and split the fees of those who don’t among attendees a la Kickback (though that model lost to POAP because of (i) added complexity during + after the event and (ii) poor implementation i.t.o. of socialz and marketing esp.
Individual login links are a nice idea - I wonder if that factors into your thinking re the calendar changes @angela?

@cryptowanderer said in Convo feature - limit RSVPs to a specific audience:

If we agree that chat is not a good way to build an ACL, then this applies to slack, matrix, or email in my mind.

Sorry, you’re right, I’m not being clear, and haven’t yet thought through a full implimentation. Was more thinking out loud to respond to the questions.

To frame this squarely, the main questions are:

Where does the source of truth (SOT) for the ACL live? And do we want to centralise it for convenience?
What type of IDs we use? (email, eth addresses, Matrix IDs, etc.)
What does v1 look like and does it corral us in a direction we want to go?

Chat Servers as ACLS

Using a chat server as our SOT prones us to lock-in, arbitary data access as an auth provider, and lack of extensibiliity if we need ACLs for gating other things in the future. I think we’re together there.

On the plus side, the decentralised access to rooms is an interesting way to distribute access control for other apps. It’s good for agency and fractalsation. Use case: Fellows being able to create their own room in Matrix and invite arbitrary members, then using that list as an ACL for other services like Convo.

My comment on avoiding was if we want to use an ethereum address as our main user ID. For example, with Slack, we’d need to store the eth address of each user in Slack metadata, and depend on Sign In With Slack is likely to communicate that metadata to the dependent apps. Otherwise all other apps depend on Slacks granularity of roles, and even if it can tell apps what rooms a user has access to, we’d end up with Slack rooms that don’t exist for any reason than to identify access rights elsewhere, like #kernel-forum-admins and #kernel-can-invite-people-to-notion-pages.

User IDs

In terms of what user ID to use, our ideal user ID is an ethereum address, but not all applicants will have one when they apply. We collect email addresses anyway for communication.

So we could still aim for eth addresses as our user ID, with email as a recovery method – effectively an accesslist of emails that allow you to create a new wallet or add an eth address to identify you. Everyone would use their wallet to login, which would then issue a JWT or process an OpenID request to provide auth to applications. Or, if we want to avoid the risks that come with rolling our own, then we use email addresses as user IDs and something like Auth0.

ACLs

Convo would need to check that ACL every time it processes an RSVP request (or at least a user login to learn the rights of the user)

When I thought though this before, I’d assumed we’d be using some kind of no-code tools for Kernel applications, but realistically, we’re going with a little chat bot for #kernel-defenders. So every week, it has the list of IDs (email or eth addresses) of the applicants accepted to the mempool.

The simplest v1 ACL is a text list of IDs. (maybe one file for mempool, one for fellows, or a CSV file that marks each record accordingly.) The simplest way to get that into convo is to send the updated list from the Defenders Bot to Convo with an API call using http auth. Or, we can have both Convo and Defenders talk to a Members API ; for Convo that would be a /check request with a bearer token that returns “no”, “fellow” or “mempool”

Matrix is going to be more complicated, mainly because access control and roles in Matrix focuses on rooms, not servers. We’d mainly need the ACL to invite and limit access to special rooms, such as the mempool rooms or fellows-only rooms, and other rooms are admined by their creators. Matrix supports SSO for login, but not room access via SSO roles. So here, our Defenders bot or the separate Members API would need to invite people to those channels when they gain access. (This is similar to Tasks in Kernel Services, where a Task acts as a super-user. The change in ACL would trigger a call to the Matrix API as a special user, inviting them into appropriate rooms.)

That’s what I’ve got so far. I don’t see a way around maintaining some mapping of various IDs.

If we wanted to do a chatroom-based auth with Matrix to avoid this mapping, it’d be a bot that room admins could invite to their room, which would track the room’s members. It would expose /roomlist and /checkmember?room=x&userid=y so that you could have a Convo dropdown of various rooms to limit event access to, and be able to check RSVP validity.

Oi vey that was long!

saintsal

A few thoughts from recent explorations:

Moving to a track-oriented architecture removes some depdendency on a more complex or centralised ACL SOT
Matrix’s User Registration Tokens is an interesting pattern to consider since it keeps coupling very loose. Each service maintains a registration token table accessible over API, limiting account creation to those with valid tokens. We distribute tokens to our new users.
The POAP Chaining system from Cuppa might be a useful direction since it’s far more decentralised/distributed (not for next block, but might help make some of our current ACL management overhead temporary) POAP Chains + OpenID w/ a website-hosted wallet (like Kernel Wallet!) gives us extensibility to do auth on all services that accept OpenID logins. I’m seriously considering picking up Cuppa again.