lexicon.community
Events and RSVPs #6
Replies: 10 comments 18 replies
-
|
I think one major area that I'd like feedback on is the concept of location collections and types of locations. In Smoke Signal, they've existed within the calendar namespace because they were used directly with events. I think this could be a candidate for moving out of that event-namespace level. community.lexicon.locations.place{
"lexicon": 1,
"id": "community.lexicon.locations.place",
"defs": {
"main": {
"type": "object",
"description": "A physical location in the form of an address.",
"required": [
"country"
],
"properties": {
"country": {
"type": "string",
"description": "The ISO 3166 country code. Preferably the 2-letter code.",
"minLength": 2,
"maxLength": 10
},
"postalCode": {
"type": "string",
"description": "The postal code of the location.",
"maxLength": 20
},
"region": {
"type": "string",
"description": "The administrative region of the country. For example, a state in the US.",
"maxLength": 100
},
"locality": {
"type": "string",
"description": "The locality of the region. For example, a city in the US.",
"maxLength": 100
},
"street": {
"type": "string",
"description": "The street address.",
"maxLength": 100
},
"name": {
"type": "string",
"description": "The name of the place.",
"maxLength": 100
}
}
}
}
}community.lexicon.locations.virtual{
"lexicon": 1,
"id": "community.lexicon.locations.virtual",
"defs": {
"main": {
"type": "object",
"description": "A virtual location in the form of a uri.",
"required": [
"url"
],
"properties": {
"url": {
"type": "string",
"format": "uri",
"description": "The URL of the virtual location."
},
"name": {
"type": "string",
"description": "The title of the URL."
}
}
}
}
}community.lexicon.locations.h3geo{
"lexicon": 1,
"id": "community.lexicon.locations.virtual",
"defs": {
"main": {
"type": "object",
"description": "A physical location in the form of a h3 encoded location",
"required": [
"value"
],
"properties": {
"value": {
"type": "string",
"description": "The h3 encoded location."
},
"name": {
"type": "string",
"description": "The name of the location."
}
}
}
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Looks great, I'm curious as to the design decision to not require a "name". To the h3 encoded location, I would add For virtual location, is there a way to require based on an "or"? Not all virtual locations may have a URL/URI |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately there aren't conditional required fields. That isn't possible at this time. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for being late to this, I see there's already a PR and I'll go add some further comments there but I'm putting the full feedback from our community discussion here for easier tracking.
|
Beta Was this translation helpful? Give feedback.
-
Yes, I think a reasonable next step would be to introduce something like this to the event structure: {
"uris": [
{
"uri": "https://example.com/"
},
{
"name": "tickets",
"uri": "https://example.com/"
}
]
}
Images, attachments, and blob handling is a future thing. This is definitely important, and I want to think through the difference scenarios and use cases. It was intentionally left out in revision 1 because it adds a lot of complexity.
Yeah, this is good idea. I'm really interested in discussing the idea of "editing" records more and getting some community feedback and consensus.
This is another thing that I'd like to discuss further: tombstones If a record is deleted (soft deleted) or is a pointer / link to a different record, what is does the pattern of an HTTP redirect look like in AT Protocol? |
Beta Was this translation helpful? Give feedback.
-
Yes, originally there was a
|
Beta Was this translation helpful? Give feedback.
-
Yeah, I'm in agreement here. |
Beta Was this translation helpful? Give feedback.
-
|
I'll do the feedback on rsvp + geo stuff in one since the first one is small.
|
Beta Was this translation helpful? Give feedback.
-
|
Here is a Partiful invite. This event could be 5 people, and my being a |
Beta Was this translation helpful? Give feedback.
-
Does the value need to be a string? It seems the main piece of information to capture here is commitment which could be represented as a percentage. That would allow implementations to use whatever labels with as much granularity as they like. eg: // TODO: Replace buttons with fancy commitment slider
const rsvpButtons = [
{
label: 'Yes',
commitment: 1,
},
{
label: 'Maybe',
commitment: 0.6,
},
{
label: 'Interested',
commitment: 0.3,
},
{
label: 'No',
commitment: 0,
},
] |
Beta Was this translation helpful? Give feedback.
-
|
To me, "interested" implies a greater level of interest, and more strongly justifies sending informational updates. "Maybe" to me conveys a lower level of interest, more passive and more like a bookmark. |
Beta Was this translation helpful? Give feedback.
-
|
On the Yes, maybe, interested, keep-me-posted, no aspect of RSVP. I'm not familiar with the schema rules for lexicons, so forgive me if this is non-compliant: Is there a way to offer a broader set of valid responses (say, five options), and then enforce that an event record defines a subset of responses acceptable to that event? Whether that is [yes,no], [yes, maybe, no] or [ yes, interested, not interested]. This allows app builders to pick their preferred set of responses. As we touch on the meaning/weight of various options (thinking of 'interested' vs 'maybe'), there is also the muddling factor of i18n; these expressions might have different weights, even to people speaking the same language, let alone when they are translated across languages. Perhaps that leans us towards including a |
Beta Was this translation helpful? Give feedback.
-
|
I'm not going to move forward with making this a complex data structure. I believe pretty strongly that it'll introduce too much complexity and will lead to a bad user experience, misuse, and bugs in implementation. Happy Path
Changed My Mind
*Will Not Go"
Non-Committed
|
Beta Was this translation helpful? Give feedback.
-
|
I think interested is good! Depending on the application, I can see someone “favouriting” or “remind me later” using this field. You might be interested because you want to share it, decide later, or just literally make interesting events. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @ebwinters on the distinction; it mainly depends on the intended signal to the three groups who are viewing this decision: the user, the organizer, and other viewers. If I had to pick between the two, I'd go with I think |
Beta Was this translation helpful? Give feedback.
-
|
At the risk of prompting wider abstraction; We have the concept of events And a concept of an RSVP But is there a concept for an invitation? Invites allow event runners to more meaningfully track who they want at an event.
Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
There isn't, but I think that it's a really good idea and something that should be explored in the future. |
Beta Was this translation helpful? Give feedback.
-
|
hosts: should an event have a property that is an array of account ids, to represent the hosts of the event? I don't know the full extend of 'ownership' of a record in ATprotocol.... can multiple entities be permitted to edit a record? Maybe only if they share a PDS? |
Beta Was this translation helpful? Give feedback.
-
|
I think we should punt this for now. At some point in the future™️ we may have permissions and multi-did records, but until then we can somewhat avoid that problem by using the field |
Beta Was this translation helpful? Give feedback.
-
|
We could group the status on two axes: 'ability to attend' in x and 'desire to attend' in y. This mapping will give far more signal to the hosts which can be useful for planning and feeding the recommendation algorithms. (1,1)=going, (-1,1)=wish-i-could, (0,1)=will-try, (-1,-1)=cant-attend, (1, -1)=not-interested |
Beta Was this translation helpful? Give feedback.
-
Representing two variables in different axes usually means they are orthogonal. Desire to attend and ability to attend seems to be related (non-orthogonal) by their variations of attendance. It would prob be better to use enumerations to denote the different states or levels of attendance: Enums for Ability to attend:
Enums for Desire to attend:
|
Beta Was this translation helpful? Give feedback.
-
|
Furthermore, the enumeration states can be mapped to a number based on their respective signals:
|
Beta Was this translation helpful? Give feedback.
-
|
I'd like to thank everyone that has contributed to this initial discussion for calendar events and RSVPs. I'm pretty happy with how #23 has turned out and I'll be merging it today. I'm going to close this discussion to encourage new discussions be created for some of the additions and changes that were brought up here. Cheers! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I want to create a new NSID and series of types to support the generic event and RSVP types within this lexicon group. These types would be part of the
community.lexicon.calendar. I think "calendar" is a good word to represent grouping of events.Intent and Rationale
Events and the representation of someone's interest and intent to participate in the event (RSVP) are somewhat generic types that can be shared across applications, systems, and tools.
For example, the Smoke Signal lexicon was created using the base
events.smokesignalNSID with event, rsvp, and location types, but they are not specific to Smoke Signal and can be used outside of that application.Types
community.lexicon.calendar.event
The event type represents a general "event" that can be in-person, online, or hybrid.
{ "lexicon": 1, "id": "community.lexicon.calendar.event", "defs": { "main": { "type": "record", "description": "Record containing a calendar event.", "key": "tid", "record": { "type": "object", "required": [ "name", "text", "createdAt" ], "properties": { "name": { "type": "string", "maxLength": 100, "description": "The name of the event." }, "text": { "type": "string", "maxLength": 3000, "description": "The event description and content for the event." }, "createdAt": { "type": "string", "format": "datetime", "description": "Client-declared timestamp when this event was originally created." }, "startsAt": { "type": "string", "format": "datetime", "description": "Client-declared timestamp when this event starts." }, "endsAt": { "type": "string", "format": "datetime", "description": "Client-declared timestamp when this event ends." }, "mode": { "type": "ref", "ref": "#mode", "description": "The attendance mode of the event." }, "status": { "type": "ref", "ref": "#status", "description": "The status of the event." }, "locations": { "type": "ref", "ref": "community.lexicon.calendar.location#locations", "description": "The locations where the event takes place." } } } }, "mode": { "type": "string", "description": "The mode of the event.", "default": "community.lexicon.calendar.event#inperson", "knownValues": [ "community.lexicon.calendar.event#virtual", "community.lexicon.calendar.event#inperson", "community.lexicon.calendar.event#hybrid" ] }, "virtual": { "type": "token", "description": "A virtual event that takes place online." }, "inperson": { "type": "token", "description": "An in-person event that takes place offline." }, "hybrid": { "type": "token", "description": "A hybrid event that takes place both online and offline." }, "status": { "type": "string", "description": "The status of the event.", "default": "community.lexicon.calendar.event#scheduled", "knownValues": [ "community.lexicon.calendar.event#scheduled", "community.lexicon.calendar.event#rescheduled", "community.lexicon.calendar.event#cancelled", "community.lexicon.calendar.event#postponed" ] }, "scheduled": { "type": "token", "description": "The event has been created and scheduled." }, "rescheduled": { "type": "token", "description": "The event has been rescheduled." }, "cancelled": { "type": "token", "description": "The event has been cancelled." }, "postponed": { "type": "token", "description": "The event has been postponed and a new start date has not been set." } } }community.lexicon.calendar.rsvp
The RSVP type represents a handle's interest in attending an event.
{ "lexicon": 1, "id": "community.lexicon.calendar.rsvp", "defs": { "main": { "type": "record", "description": "Record declaring an RSVP for an event.", "key": "tid", "record": { "type": "object", "required": [ "subject", "status" ], "properties": { "subject": { "type": "ref", "ref": "com.atproto.repo.strongRef" }, "status": { "type": "string", "default": "community.lexicon.calendar.rsvp#interested", "knownValues": [ "community.lexicon.calendar.rsvp#interested", "community.lexicon.calendar.rsvp#going", "community.lexicon.calendar.rsvp#notgoing" ] } } } }, "interested": { "type": "token", "description": "Interested in the event" }, "going": { "type": "token", "description": "Going to the event" }, "notgoing": { "type": "token", "description": "Not going to the event" } } }community.lexicon.calendar.location
The location types represents collections of and individual physical and virtual locations in which an event takes place.
{ "lexicon": 1, "id": "community.lexicon.calendar.location", "defs": { "locations": { "type": "array", "items": { "type": "ref", "ref": "community.lexicon.calendar.location#location" } }, "location": { "type": "union", "refs": [ "community.lexicon.calendar.location#place", "community.lexicon.calendar.location#virtual", "community.lexicon.calendar.location#h3geo", ] }, "place": { "type": "object", "description": "A physical location in the form of an address.", "required": [ "country" ], "properties": { "country": { "type": "string", "description": "The ISO 3166 country code. Preferably the 2-letter code.", "minLength": 2, "maxLength": 10 }, "postalCode": { "type": "string", "description": "The postal code of the location.", "maxLength": 20 }, "region": { "type": "string", "description": "The administrative region of the country. For example, a state in the US.", "maxLength": 100 }, "locality": { "type": "string", "description": "The locality of the region. For example, a city in the US.", "maxLength": 100 }, "street": { "type": "string", "description": "The street address.", "maxLength": 100 }, "name": { "type": "string", "description": "The name of the place.", "maxLength": 100 } } }, "virtual": { "type": "object", "description": "A virtual location in the form of a uri.", "required": [ "url" ], "properties": { "url": { "type": "string", "format": "uri", "description": "The URL of the virtual location." }, "name": { "type": "string", "description": "The title of the URL." } } }, "h3geo": { "type": "object", "description": "A physical location in the form of a h3 encoded location", "required": [ "value" ], "properties": { "value": { "type": "string", "description": "The h3 encoded location." }, "name": { "type": "string", "description": "The name of the location." } } } } }Beta Was this translation helpful? Give feedback.
All reactions