Project Ideas

From LID Wiki

If you are interested in working on any of these, please add your name and/or project page so there's no unnecessary duplication of work. You may also want to first post to the LID Developer Mailing List.

Contents 1 Open Source Projects 1.1 Mailing list managers 1.2 Blog software 2 Protocol Design Projects 2.1 LID URL transition protocol 3 New LID Profiles 3.1 3rd-Party Delegation Profile 3.2 LID 2.0 PubSub

Open Source Projects

Mailing list managers

• allow users to subscribe to GNU Mailman not only with their e-mail addresses (which can be spammed), but instead with their LID URLs (which are harder to spam). This would entail:
  • make Mailman recognize LID URLs as valid identifiers
  • use one of the LID Authentication mechanisms (e.g. OpenID) to authenticate a subscriber's messages against the Mailman installation. No more forgotten mailing list passwords. There is already OpenID support in Mailman , so taking it from there might be the easiest approach.
  • Forward messages using the LID 2.0 POST Receiver Service (both from the list to the subscriber, and from the subscriber to the list)

Blog software

• Add to a blogging package code to use LID as a mechanism to authenticate blog comments.

Virtually all blogging packages could benefit from this. Various Six Apart products (e.g. LiveJournal) support authentication via the OpenID sign-on protocol already, and are thus LID compatible.

Dan Lyke has already added it to Flutterby.

• Add to group blog / community site software code to:
  • recognize external LID URLs as valid identifiers, enabling SSO.
  • become LID URL providers themselves, for their user base.

Protocol Design Projects

LID URL transition protocol

• design a protocol by which a LID owner can notify a person or site that she will stop using one LID URL and will now use another. The protocol must enable that person or site to authenticate the notice.

Include a discussion of how that person or site can proceed to "migrate" their records. The protocol should consider two cases: the first LID URL is no longer owned (or will no longer be used with any person or site); the first LID URL is still owned and may still be used, but not with this person or site, instead the second URL will be used in the future. (If these cases are, for all practical purposes, the same, show that.)

Perhaps this protocol would best be followed with authentication with the current LID URL, providing the new LID URL.

New LID Profiles

3rd-Party Delegation Profile

See LID_2.0_3rd-Party_Delegation_Profile.

LID 2.0 PubSub

We need to design LID_2.0_PubSub. We should take Jabber PubSub into account, as well as what pubsub.com does. It needs to work only bright-to-bright in the 4-Point Architecture.