I’ll be posting a weekly “Current State of Things” with subheadings “Changelog” and “Current Focus”
Changelog would include all the changes since last week that can be seen in the app
and Current Focus would include what I’m currently working on
This would be a fairly technical update
I’ll be converting discussions from here into tasks and put them on the Taiga board - that is the place to look into if you want to see all that’s currently work in progress. [need to update]
We currently have two versions of Convo: v1 and v2.
The reasoning behind upgrading it this way was because we wanted a bunch of new features that required changing quite a lot of backend and the database schema. Because Convo was being heavily used when I started (the block was still running) it didn’t make sense to upgrade the sort of stable app.
Current Focus
Upgrade to v2: move convo subdomain to point to the v2 version of the app
For this to be possible, I still need to work on some features:
Confirmation state (after submitting the form and after RSVP)
Access controlled events (adding an option to token gate a particular event - the idea is to eventually add simpler gating as well, eg., slack auth)
filter button on home (/) and upcoming (/all) page to filter for the events that have been allowed for the tokens in the user’s wallet - if signed in. If not signed in, will just see public events
either upgrade via Vercel or our server if we get to fix the hosting issue before then (and turn off Digital Ocean server)
Changelog
What changes in v2?
sign in with wallet: required to propose an event and RSVP
RSVP flow: click on RSVP → a modal that asks for email and/or a display name
is there a specific reason we don’t want emails at all? (thinking if it’s worth the complexity)
#proj-hea: care space rituals require a form to be filled before someone RSVPs, currently Aliya fetches the emails and shares with them, they send the form and if the form isn’t filled by the user they are ok with opening up the slot for someone else
require approval (checkbox) + event specific thread between proposer and RSVPs
probably not the best solution, but would this solution get us one step closer to probably a better solution?
As an event creator, I’d like to message all the people who have RSVPed to my event.
As an event creator, I’d like to know exactly who is attending my event.
Not all events need this, but #proj-hea was a nice test case for one that does.
I still think email as a secondary behind wallet is a no brainer and opens us to the future.
Until wallet communication is strong (message / notify people based on their wallet address), we’ll need to find other ways to address these user stories well. Angela had some good ideas for doing so which we can roll out v2 with, including chat on event page / the checkbox requiring email or requiring approvals as a host.
Both can work (let’s crawl / walk / run and not let scope run too large), would like to feel good about a cutover soon as KB8 approaches.
specifically on: collecting emails as an additional (and intentional) step after clicking “RSVP”
why we need this - so we can decouple google calendar events with convo events, we want this so we can make email an optional requirement.
Current Focus
adding a google service utility that would send calendar invite for a particular event when a potential attendee submits their email
add a checkbox in the propose form that toggles creation of a google calendar event on the main “convo” shared calendar - if this is unchecked, the rsvp modal would not have an option to input email to receive invite - only to download the calendar event file