Distributed Calendar+discussion
My thoughts about notifications are along these lines. When you publish to a circle (could also use "membrane" term, but let's stick with circle in our design), this will be in the context of a publisher implementation (the system, not just the agents who publish through it), so that implementation handles all of that.
There will be a static and dynamic concept here, the publishing system will maintain a static view for any circles it supports locally as well as provide all the options for dynamic actions (notifications via email, twitter, whatever). Our reference implementation will have some set of supported protocols and methods, and ODC networked implementations can do these and/or some others they need for their users.
There should also be efficient protocols for networked servers to keep each others circles in sync, but in principle each participant only needs to worry about the circles they are in.
Thinking about some details. I think we need to dig into the different agents and how they get instantiated.
Pragmatically, we will have a network of ODC calendar instances, and we need some way(s) for the instances to know about each other and communicate. I'm thinking there should not be a fundamental difference between an instance associated with a large organization or a personal instance on a smart phone. Being a publishing instance will probably commit you to respond to certain requests as long as you have any published events in play.
I think we can just say that authentication and identity of circle owners and publishers is up to the overall calendar application. Circle membership and identifying participants and resources doesn't have to be closed. If it is, it can be fully internal to the app, but if it is open you can use open invitation with RSVP protocols.
We will want to put our attention on the open cases, but fully support organizations with different needs. Most of the time they will need both the open protocols and closed ones they are required to use.
Talking through a common use scenario. I run an ODC instance and semi-private calendar. Initially just for myself, but eventually maybe a small group of collaborators. There are some orgs, OrgA, OrgB, ComC, etc. in my community and I might work and volunteer for one, on the board of another.
Most circle members will have an account or maybe simply an event registration at different ODC instances, but I have a personal ODC calendar app on my phone and laptop. When I look at my calendar, I can have views with more or less circles shown, and filtering for level of commitment at well. I can look at all invitations from all circles and see the maximal conflict calendar. When I commit to an event, (proposed ODC process), I make a local clone of the event and add myself to it. I can now publish that back to the source where I would be reflected in the participants lists.
My sync channel to events will generally be ODC-ODC protocols based on FedWiki concepts. Most of the calendar data will be pulled locally via ReSTful (likely JSON, but agnostic) updates. The register/publish participants update exchange will follow patterns like FedWiki. I change my copy of the source data and tell the source about it. The source pulls the update (or my 'tell the source' could include the update for simplicity) where the change gets published out to others.
Note on simple broadcast invitations. A standardized ODC tweet can be received from any publisher you follow and maintain skeleton events that can potentially be fetched from their source based on local rules and clicks.