expand_less
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: "participant circles"visibility: public or private with circlemembership: people in the circleproperties: 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 (see below) Implemented as "rules" in the participant circle publisher roles owner roles member roles
Core Concept: agent 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
Core Concept: "notifications" Notifications are received when an event is created or changed. TBD: how are notifications published to all participants in the event circles? TBD: how are notifications sync'd when a participant re-connects? TBD: how are notifications authenticated? * 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 eventCore 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
Core Concept: Notifications twitter et al email smsThe 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."
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.[[http://fed.wiki.org/|FedWiki]][[FedWiki|http://fed.wiki.org/]] 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 ...
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: "participant circles"visibility: public or private with circlemembership: people in the circleproperties: 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 (see below) Implemented as "rules" in the participant circle publisher roles owner roles member roles
Core Concept: agent 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
Core Concept: "notifications" Notifications are received when an event is created or changed. TBD: how are notifications published to all participants in the event circles? TBD: how are notifications sync'd when a participant re-connects? TBD: how are notifications authenticated? * 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 eventCore 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
Core Concept: Notifications twitter et al email smsThe 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."
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.
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 ...