Distributed Calendar
As an organiser and social media participant, I want a really flexible calendar application.
It should keep a personal calendar with private events mixed with events posted to distributed calendar instances. It is assumed that most users will already have a calendar app, therefore see the software developer story below. We can provide a simple web-app or phone-app calendar as a reference implementation, but more important will be to get calendar app developers to share our distributed protocols.
It should allow organizations and individuals to publish events to different circles of participants and for the participants to register and modify commitments.
The 'participant circles' could also have different properties, like open or even non-registered acces (as with Wikipedia), all the way to totally closed enrollement controlled by a sponsor or owner. Publishers publish to them, and members are in or out of them.
As a participant, I should be able to get notification when new events are posted, or there are changes to events I have pinned to my calendar. I should have the option to add new events or modify commitments when changes produce conflicts.
As a software developer, I need a simple and flexible interface to enable distributed calendars in an existing or new calendar app. I want a strong incentive to implement these protocols, and that incentive should be a rapidly growing number of calendar apps supporting this.
The representation of events needs to be very flexible, and be translated to some standard semantic tags. Events can have all sorts of details, when, where, how long, etc. but only some details in the where and when need to be accounted for in standard tags. The when has to lock a block of time on committed participants schedules, and the where commits a participant to handling certain logistics and block out more time for that. Since these details are only the concern of the individual being scheduled, how they are handled internally isn't important. It will often be totally manual for the user when any when or where change comes in, but in principle it could be a smart agent helping to automate scheduling for a very busy user. It might know about locations and be able to compute accurate travel times and even change reservations.
As an administrator in an organization, I need to empower my organization to maintain many calendars and schedules. I need tools that I don't have to work to integrate. Internally, there are a number of circles of authority and work that need coordinating. They overlap and integrate in many ways. Externally, our organization plans events and signs up volunteers and participants.
As an administrator, my internal and external members all want our calendars to support Open Distributed Calendar (ODC) protocols, and I'm making that a requirement on all of our calendar applications.
As a developer, I need to provide ODC support for key customer requirements. I hope it is easy.
Core Concept: ODC calendar instance
visibility: public (publishing) or private (personal)
membership: all circles, roles, participants and events are "owned" by an instance.
publish contract: While an even is active, a 'source' is supplying authoritative responses and broadcasts per channel protocols for the subscribed circles.
channel representations: will be largely controlled/determined when published or when possible overrided by request options.
attribute neutrality: simple key/value exports and standard serializations for events.
properties:
open: any ODC compatible cliient/server can play (P2P). At least one instance is referenced as the source for "authoritative" interactions about published events.
Core Concept: "participant circles"
visibility: public or private with circle
membership: people in the circle
properties:
open: anyone that is a participant in the circle can register in an event
non-registered: anyone, even those not currently a participant in the circle, can register for an event
private: event may be visible to others, but only the participants in the circle can register for the event
Core Concept: "event"
events are associated with one or more participant circles (allows an event to span circles with interested parties)
when / where / duration - typical calendar stuff, including recurring, etc.
event has_at_least_one owner(role)
Core Concept: roles -- these are considered 'local' to the ODC implemtnation (see below for role usage)
Implemented as "rules" in the participant circle
publisher roles
owner roles
member roles
Core Concept: agent (generally in an ODC instance these will be the logged in user)
It is agents that havre roles to participate
We should distinguish bots and people somehow, but it general an agent might be either
How the agent's identities are established in the real world is at the level of use and human (social) protocols and architectures.
Core Concept: resource
This is a special agent-like concept that can be used for various resources you may want to reserve to service an event. Say you wanted to be able to livestream meetups of your circle. A video-team could be defined with specifications of their capacities, or this could be catering, etc. The room inself including conference phone and projector with the right configuration for presenters to use.
Core Concept: "publisher" (agent role)
People who can create events on a participant circle
depending on the rules of the participant circle, 1, some, or all people can be publishers
rule: a participant circle must have at least one publisher
Core Concept: "owner" (agent role)
one or more publishers should be designated as owners with the ability to add/remove other members.
rule: a participant circle has at least one owner
rule: owners have certain special permissions
Core Concept: "member" (agent role)
People who are part of the participant circle and can indicate they are attending an event, abstractly, these agents have read-only access except with reguard to their participation in circles and events.
Core Concept: "notifications"
Notifications are sent when an event is created or changed.
- twitter et al
- sms
The idea being that people can subscribe to a circle and get notifications of new events/changes through different notification mechanisms. This is an excellent example of how an edge receptor is used to communicate to people through existing "channels of communication."TBD: how are notifications published to all participants in the event circles?
TBD: how are notifications sync'd when a participant re-connects? -- channel specific protocols
TBD: how are notifications authenticated? -- member profile authentication (i.e. concern for ODC instances)
* new events
* changes to events (time/place/duration/cancellation/etc)
Core Concept: P2P (distributed events)
Each peer maintains their own events
Editing an event locally (if the rules permit) are sync'd with other peers in the circle(s) associated with the event - (use FedWiki distributed change model if at all possible)
Core Concept: Semantic events
Events are semantic, with basline concepts, such as where, when, duration, topic, etc.
Baseline semantics are translated into whatever format is necessary to place the event into the app(s) the user has (as in, edge receptors)
Support Open Distributed Calendar (ODC) protocols - this probably guides the baseline semantics
Semantics can be extended for new apps that have "receptors" that understand additional semantics
ex: a spontaneous crowd meeting of musicians in a public park, and the additional semantics might specify music genre, instruments needed, etc.
Extended semantics are part of the "schema" associated with the participant circle definition
Other important things to consider that Gerry mentioned in a Slack conversation:
Connecting to calendars and holochains, the nature of all these structures is similar. Content and a flow of changes are tracked back to sources. In ODC, if I see a typo in my personal calendar view of a distributed event, I can pull and fork the event in my local and even republish as a correction to the original. My change is authoritative for me and anyone who wants to take it, and the publisher is still authoritative for all of their circles. They may, of course, accept my offer of a fix and pull my change in. FedWiki has the model for that part all nailed already.
re: holochains and ceptr:
In a holochain, I have some keys that I'm working on, adding to, exchanging with others (via cetpr-like bots and apps), and there are some number of keys that are "in play", and another number of "boundary keys" that are already trusted (having trusted sources or having actually been traced to roots before we started "playing")
Anyone can create new entries that connect back to these key sets and put them in play. They are in play to the extent that anyone is listening to them or cares. If branches are created and lost because no-one but their source has recorded them ...