@flo-bit.dev and I talked on the atmo.rsvp private events PR about which space type private events should use. I’d like to ask: should calendar apps share one space type, or should each app keep its own? I suggest a shared one below, and I’d like to know if the community would use it.
A space is a set of records with its own rule for who may read them (spaces proposal). Its type names the kind of content, and apps ask for permission by type.
atmo needs a lasting space type before private events leave beta. We could publish an atmo type now, but other apps would have to add support for it. The type is part of every space’s address, so changing it later means every guest has to come back and answer again in the new space.
Where things are
- atmo.rsvp private events (PR #105, open) put each event in its own member-list space on the host’s account. Guests write their RSVPs in their own repos, inside that space. atmo keeps no copy: it reads each event with the viewer’s own access, so the host’s server decides who sees it. It uses a temporary type,
rsvp.atmo.dev.space, behind a beta setting. - Tandem writes its records, under
space.intandem.*, into the host’s own space (scheduling proposal).
Why share
- Guests can answer from their own calendar app, not only the host’s. Calendar apps already share the event and RSVP records for public events for the same reason.
- Private events stay usable if the app that made them goes away. Another calendar app that supports the type can open them.
- One app can show all your calendars in one place and work out when you’re free.
- It’s easier to agree now, before each app has data under its own type.
Separate types can still work together, but each app has to add support for every other app’s type, or ask for access to every space of every type.
Why not
- By default, a read grant for a space type covers all your own spaces of that type. Apps can ask for particular spaces instead. So an app you let into “your calendars” can read the private events and RSVPs in all of them. You might trust one app with that, but not every app.
- Each space sets its own rule for who may see it: a member list, everyone the owner follows, or whatever a group’s own server decides. An app that keeps a copy of a space and shows it to many people must follow that rule. Apps sharing a type need compatible rules, or a way to recognize spaces they can’t show.
- Apps that use a type’s default list of collections can gain new write permissions when that list changes, without asking the person again. Sharing a type means trusting whoever controls that list.
Where I lean
I lean toward a shared type meant for events and RSVPs, with those two as its default collections. That list is only a default. Other kinds of records can still go in a space.
I’d like to hear feedback.
The type I’d suggest
{
"lexicon": 1,
"id": "community.lexicon.calendar.space",
"defs": {
"main": {
"type": "space",
"key": "any",
"name": "Calendar",
"collections": ["community.lexicon.calendar.event", "community.lexicon.calendar.rsvp"]
}
}
}
The name space is open to debate. It sits next to event and rsvp and reads as “a calendar space”.
With key any, an account can have many spaces of this type: one per event, one per group of friends, or one for a group’s calendar.
Questions
- Would you use this type for what you’re building? If not, what would need to change?
- What are you doing with private calendar data today, and which space types do you use?
- If your app keeps a copy of space data, how do you check who may see it?
- Should the availability and booking records in Bryan’s scheduling proposal (linked above) go in calendar spaces, or in a type of their own? Availability could hold busy blocks that don’t say what the event is, so a booking app can compare times without reading your events.
Let me know what you all think.
