Ever since the Strikethrough of '07 -- actually, ever since I realized that LJ was something of an attractive nuisance of basket in which to store eggs, way back when -- I've been thinking about how one would go about turning LJ, the software, from a client/server model to a peer-to-peer model. That is, how to make LJ distributed
(
Read more... )
Absolutely. However, I was thinking about a slightly more complicated application which could be considered "gravy", except that it is necessary to the importation of LJs. There needs to be an interface for the LJdist owner to say "lj:user{londo} == myljdist:user{londo@centauri.gov}". Once you have that, it seems tempting to say, "Let's make that a 1-to-many!" so that you could also say "lj:user{londo} == myljdist:user{londo@ambassadors.b5.gov}". Then you could authenticate against either server -- which has the awesome property of giving you backup authentication. Because one of the interesting properties of this architecture I've been thinking of is that if your site goes down, you can't access anybody else's site, either, as a logged-in user, because your site isn't there to authenticate against.
However, that raises the question of how that user ID will be rendered to users. If we simply render it londo, that sort of "short name" can't be guaranteed to be unique. (Though I could totally see doing the "unfair" thing and privileging LJ user IDs as short names.)
But, yes, we could simply always use "username@theirdomain.tld".
Reply
Leave a comment