Stateless Distributed Membership an Inquiry

From IIW

Session: Wed Session 2 Space E

Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes

Convener: Judi Clark

Note-taker(s): Judi Clark

Tags:

openID, identity, personal data store, user-managed access, access control, social expectations, how things work, multiple identities, experiment

Notes:

We explored the possibility of creating a membership site that does not have a traditional membership database (user names, passwords) but instead uses OpenID (or similar) and personal data stores to contribute to the site. A lot of the underlying tools/technology exists already.

  • Eve M has spoken about ID data statelessness and this concept is related.

Access to the site (example): OpenID, location to personal data store, and default designation of sharing policy. Sharing policy might include, for example:

  • Sharing: A. Sharing; B. Others in this thread; C. Specific others
  • Storage: 1. cache & call to update, 2. no cache; 3. X days; 4. Permanent until revoked
  • Related concept: cache and update
  • Recommended reading: Future of Reputation (Solove)

First example: Forum/Conversation

My server stores a unique transaction record key, the openID & policy statement, and other pointers relevant to the specific interaction. For example: if visitors are contributing to a forum or ongoing conversation, my server may have a time/date/conversation ID stamp (each contribution is stored on the visitor's own personal data store (PDS); my server assembles the conversation according to stated policies and availability of visitor PDSs.

  • Example of distributed conversations: blog posts and trackbacks
  • important underlying concept: Operational Transformation (wikipedia)
  • Might try installing a version of Google Wave/Jupiter to start

Second example: Personal RFPs

Similar to a job board or public wish list, my server might offer a commons area which points to Personal Requests for Proposal (RFP) for something that someone wants or offers. A common template for an RFP might include a title, description, price, and way to reach requestor, stored on the requestor's PDS. My server tracks the pointer to the PDS that holds the RFP, a community caution flag, the REL button status, and an expiration date.

General consensus that this was an interesting problem from social angle as well as having many tools that might be applicable. Many of the social norms and expectations have to be discovered or developed & discussed.

Thanks for the very constructive questions, suggestions and observations at this session!

Retrieved from "https://iiw.idcommons.net/index.php?title=Stateless_Distributed_Membership_an_Inquiry&oldid=3639"