Convo feature - limit RSVPs to a specific audience
-
@angela I have put together a very high-level wireframe for this feature you have prioritized, as I see it my mind.
Wireframes like this are great, because they flush out much more interesting a specific questions for us to work through together. I think they will be a nice way to link use cases with features and work together on designing and implementing the features such that they really do cover the use case fully.
My questions are written out in the frame. Basically, I know we said a radio button at first would be good enough, but I do think it’s worth doing v1 with a drop-down menu already, as we will definitely want it to evolve to greater and greater flexibility.
Specific question for you @angela about whether slack verification can be granular enough to distinguish full members from multi-channel guests if we want to limit attendance to only people “on chain” (i.e. fully in Kernel) or just in the “mempool” (which means they are multi-channel guests).
Two specific questions for you @saintsal
- Can matrix provide us with similar verification criteria based on the research you’ve done so far?
- How do we better link selecting an audience with the notification stream? I feel like there is a fascinating and potentially powerful can of worms in this simple thought…
General question for everyone:
How do we approach surfacing real engagement in convos (i.e. not just RSVPs, but actual attendance) without breaching privacy or making it too game-able?
-
@cryptowanderer Small request before I can reply to the message more thoroughly: I’m unable to see the text in the attached image
-
Moved from Priorities by
saintsal
-
@cryptowanderer said in Convo feature - limit RSVPs to a specific audience:
Can matrix provide us with similar verification criteria based on the research you’ve done so far?
At first glance, it probably won’t be as easy as an API call. Either we sync as a client, and parse out room invitations, or we run a bot at that monitors who joined the mempool channels. I still need to check the Server to Server API though.
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:
How do we approach surfacing real engagement in convos
How about an individual login link for each user with a random code. That link records the click, and forwards the user to the actual login.
-
@saintsal 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:
Notion hell as before (people use this email for the RSVP, that email for slack, another for convo)
I hear you, but I’d like to double check if it’s the same situation without third-party services and previous accounts.
@aliyajypsy would we have the same problem with our own services? What I imagine happened with Notion and Google as that people already had old accounts with different email addresses. Here we could say “what email address will you use for Kernel services” and use it for Matrix and Convo. We don’t have to worry about what email address they signed up with in the past, for Notion, Google, etc.
On this note, I can see existing matrix users might want to use their existing Matrix ID, but we can also ask for that upfront. “If you already use Matrix, would you like to use your existing ID on Kernel’s server, or would you like us to create a @user:kernel.community ID for you?” This could all be in the same place where we ask for their eth address.
The question then is how do we sync. I’d suggest manually at first (admins can copy/paste the latest allowlists into convo or the matrix server) and we could make a little allowlist REST API to do this automatically.
If we really want to do it properly, I think we need our own OpenID provider. Then we manage ACL in one place, and have a future proof and for-purpose standard to integrate Convo, Matrix and anything else. ( Kernel Wallet w/ jwts wo/ storage + Wallet Connect + OpenID auth is high on my list of projects. It’s a standalone wallet product that’s unique and EIPable, and pulls the core educational value and vision out of Kernel Services. Difference it’s way less complex, hits a simple horizontal use case, and therefore has a lighter, less complicated launch path. It’s something we could do for kb9 without too much stress. )
-
@saintsal i don’t foresee as much as a problem as the scenarios in which people have previously established accounts with various email addresses such as notion, slack, or gmail.
however, one potential remaining issue is people wanting to use their work email (because maybe the domain gives them clout - such as microsoft, google, uniswap, whatever - which they believes grants a certain status) and then it becomes null when they move to a new employer.
in the kb7 typeform application, we strongly suggested applicants used a ‘forever email’ e.g. not a work email, because we want to be able to remain in touch with them fluidly, even when they change employers
-
@aliyajypsy @cryptowanderer Thanks. I’ll leave it to you two to assess the magnitude of this problem; I just wanted to ask the question.
I wonder if it helps any or hurts any that we’d be onboarding ~50 at a time every two weeks. Maybe fewer makes the exceptions easier to handle, but every two weeks gets annoying?
I really need to get the unconf app ready for you to see. It has a wallet sign up that flows like Trust Wallet, where you save your seed phrase and that’s it. (Completely based on Kernel Wallet’s underlying etherjs tech, just using a standard seed phrase instead of the file download, and using Trust Wallet’s UX-tested flow.) Using that by itself (without the unconf part) gives us a primary ACL option of sorts, where each app like convo would still check against an allowlist of addresses. We just wouldn’t need to collect them in a form or collect emails for login purposes (just to email them emails). If someone loses their seed phrase, we need a way to verify them and send them a signup link - I guess to their email address on file.
-
@saintsal with respect, I find your reasoning opaque and difficult to follow.
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. It makes no sense to say “let’s do email” when we know it causes ops overhead (even if reduced here), especially given that it requires so many additional implementation steps (manually syncing, a magic API etc., as opposed to just calling slack’s API once for a v1 implementation now).
Happy for us to have a go at a standalone “access provider” for kb9, but that’s not relevant to this thread currently.
Even happier to see the unconf app whenever you’re ready.
@angela we await your thoughts here
-
Forked by saintsal
-
Moved from Kernel by saintsal
