Log in

distributed blogs [entries|archive|friends|userinfo]
distributed blogs

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Userid structure proposal [Dec. 6th, 2007|05:30 pm]
distributed blogs


The following idea just hits me a few minutes ago, it may contain holes of the Grand Canyon size. But I feel myself brave enough to insert my two copecks... How should userid in our system look like? Plain unstructured namespace is not an option: distributed system have then no way to know where to seek any necessary data for this user. Traditional user@server is better, but still not perfect: servers in our system are (by presumption) unreliable. Worse than, the experience from traditional Internet (and FIDO with its node.point scheme) reveals that user forced to change his server is inclined to keep his username. And when system grows out of "friends net" size, usernames squatting problem arises.

So why not to move one step further and not to invent three-part names? Call them "first name", "middle name" and "last name". When user is registered in the system at the first time, his new userid is of traditional user@server form. Later, if (or rather "when") the origin server shuts down, or user chooses not to use it anymore, or server admin chooses not to host this user anymore, then user can move to any other server, and his userid became user@server.old#server.new (I do not insist on this exact separator, I just took the char next to "@" on keyboard). Four-part userids never appears, but the last name can change unlimited number of times.

Consequences: (1) Server admin can deny its service to any user in any time, but she cannot revoke the claim that he was hosted sometime in the past, (2) the protocol of proving you identity when you are getting a new last name is to be discussed, (3) usernames squatting is almost no problem, (4) I cannot predict social consequences of having the middle name of died and buried long ago server (maybe this become a sort of knighthood order, maybe not).

Any ideas?

... tu'a ro se jdanu'e cu se xalbo ca le co'a vensa ...

Link14 comments|Leave a comment

Hidden comments vs deleted comments [Dec. 6th, 2007|03:50 pm]
distributed blogs

In the LiveJournal it is a common practice to send private message to blog owner by commenting any unrelated post and immediately deleting comment afterward. Blog owner recieves comments by E-Mail, and other don't see it. This practice became unsecure since LJ provided way to subscribe to comments in other people blogs. But many people still use it anyway.

In the distributed blog system this practice is definitely unacceptable. There are two much chances that either comment would be deleted too soon and never propagate where blog owner can see it, or it would deleted to late (due to internode connectivity problems etc).

I've got an idea how to make private messaging system nearly equivalent in user experience, but secure.

We should let user post hidden comments to other people blog. In my original cryptoblog proposal hidden comments are encrypted just for blog owner, and only blog owner can decide to open it for all entry readers (all , if entry is public) or just delete.
So if commenter can mark comment as hidden, he can be sure that nobody would see it before blog owner and without blog owner concent.

Of course, there could be private messaging system, totally separated from blog comments, but LiveJournal recently got one, and how many people used it? I've never got message from anybody via this system.
Link11 comments|Leave a comment

Changes to wiki [Dec. 6th, 2007|02:17 pm]
distributed blogs


Disregard http://community.livejournal.com/d_blogs/1874.html message.

Please feel free to edit wiki pages - they are stored in SVN, for example http://dist-blog.googlecode.com/svn/wiki/BasicConcepts.wiki, so change log is available via svn client. Please make sure that you've entered a description of change before submit. Do it using "Edit log message" link at the bottom of edit page.
LinkLeave a comment

Some more thoughts [Dec. 6th, 2007|10:54 am]
distributed blogs

on the subject (I guess we'd better start making some sort of order in this, or we'll be lost soon).

nchaly raises the issue of local backups. I say - it's out of scope. And this is a good time to define what IS the scope.

My vision at least is of a module that can be integrated into the existing blogging engines - instantly making any blogging service using them into a node in the network. We should see whether it is at all possible (looking at a specific example - say, LJ with it's open source - will make it easier). If indeed it is a viable concept, it will greatly ease both the development of the service, and its acceptance by the public.

And back to the issue of local backups, I say - if we already have mirroring of content on multiple sites, and if we aim at small and medium sized nodes, we should allow for no local backups (I can't imagine a home user buying a RAID and performing regular backups).

As for a replication - I had a thought on this as well. Currently the major stumbling block for replication is content of limited visibility (friends only and such). But if the content is encrypted in such a way that it is anyway visible only to the intended recipients, why not distribute it all for all to read? All you have to do is plant all of user's posts and all of the comments to his posts into an RSS, and everyone who wants to mirror this users' journal, can do it. I'll tell you why not:
1. The fact someone has posted something (even if you can't read WHAT was posted) is also knowledge being leaked. But LJ leaks it too: you can see the counter of number of posts being posted increase with every post (even a private one). Not a biggy, if you ask me.
2. Material for a dictionary attack. Well, well, I don't know, not really a problem if you ask me.
3. This RSS will be used both by the mirroring nodes and by users' browsers. There should be a way to let the browser know not to display certain items, unless he can read them.

Your comments are welcome.
Link3 comments|Leave a comment

Avoiding reinventing the wheel [Dec. 6th, 2007|11:53 am]
distributed blogs

During the more than 20-years history of internet, a lot of standards which can be relevant for our problem were developed.
These standards are typically based on big amount of reaserch and address problems which new developers are not even aware of.

So it is good practice to use existing standard whenever available, instead of inventing something own.

Which standaras can be relevant to distributed blogging?

1. HTTP and (X)HTML - these standards and their implementation in web browsers and web servers made entire fenomenon of blogging possible. Every user of internet has browser, and can read HTML pages via HTTP protocol. Since blogging is public activity, than
content which is not intended for limited auditory, should be available for casual user, which have nothing more than browser.

HTTP is very flexible protocol and can be used for interserver communication as well as in server-to-client communication.
There are extensions to HTTP which allow remote procedure call interfaces over HTTP (XML-RPC, SOAL) filesystem object manupulation with versioning (WebDAV) etc. These extensions are well supported by existing software.

2. Digital singing and public key encryption.
Digital signing is tricky thing. Existing digital signature algorithms sign sequence of bytes, while blog entries are formatted text which can be reformated during integration into variouws feed, friend-tape etc. There are two ways to handle this situation:
sign text as byte stream and base64 encode it or use some canonization method which allow to format same message into same stream of bytes regardless any reformatting which do not change content of messages. Later is covered by RFC 3076 and signature syntax by RFC 3275. I prefer this way, because it leaves message clear-text and readable by casual user who doesn't have cryptography support in the browser.

Encrypted messages are better handled by former way, because they shouldn't be readable by non-authorized person, This is covered by RFC 3852 also known as PKCS#7.

3. Cryptography support in browsers

Browser already have some limited cryptography support. Mozilla and Konqueror have window.crypto object which can generate keypairs and sign texts. Unfortunately, there is no support for verifying signatures and encrypting/decrypting. Underlying cryptography library libnss does support all neccessary algorithms and formats, there is just no interface on the client-side scripting level. Although there can be Javascript interface on XUL level, I'm not aware of.

Internet Explorer can implement all cryptography functions using CAPICOM Active-X object. Unfortunately this object is not included into default Windows installation and have to be downloaded from Microsoft site.

Less widespread browsers such as Konqueror and Opera typically implement Mozilla-compatible interface

4. Secure connections

There is standard for encrypted and authenticated TCP connections which can be used for any TCP-based protocol - TLS (RFC 4346) also known as SSL. Since it is already implemented in all browsers and there are a lot of publically available implementations, we do not need to concern with protocol details. We should only take into account basic security principles of this protocol. Most basic one is that server have to be authenticated using public key cryptography, otherwise connection cannot be considered secure regardless of encryption strength. If we are not sure whom we communicate with, what's a talk about security. Client authentication is a bit less important. Once secure (encrypted) channel to trusted server is established, client can authenticate itself using other methods such as passwords.

5. Public key infrasturctire

Both digital signing and encryption and TLS rely on the public key infrastructure. They need reliable and trusted way to find out whom public key belongs to, or even (in case of encryption) find out which public key of particular person to encrypt message for him.

There are two standartized types of public key infrastructure - X.509 (RFC 3280)
and decentralized Web of trust used by whidespread PGP/GnuPG programs.

X.509 has an advantage that it is already supported by browsers and various server-side TLS implemetations, but most people thinks that it is strictly centralized - requires that public keys should be signed by some official Certification Authorities,
such as VeriSign, which charge a lot of money for digital certificates. Really, it is not true. Certification authority is, by definition, someone, whom your browser trust identifying other parties. Nothing more. So it is quite possible to implement web of trust concept using X.509 certificate format.
Link20 comments|Leave a comment

Changes to Wiki [Dec. 6th, 2007|10:43 am]
distributed blogs

I see you guys are starting to make changes in the Wiki. Good! But unfortunately, code.google does not keep a history of changes, so we can't see what's actually been changed. Perhaps, we should keep this history manually somehow. I know it's a hassle, but what choice do we have? So either we'll keep a copy of the wiki pages in svn, or we post here the changes we do. What do you say?
Link15 comments|Leave a comment

SVN [Dec. 5th, 2007|10:35 pm]
distributed blogs

If you only want to have a read-only access to the repository, access it anonymously at


If you want to take an active part in the project, please send me your e-mail (unless you know I have it already - then just let me know you want it) and I will add you to the project. Then you will be able to checkout at:


I've already checked in the file with the Q&A we started in my journal, and I will be updating it soon with your suggestions. Soon it should be reworked into a well-structured concepts and design document.

Come to think of it, I put the concepts file into Wiki. Go ahead and comment on it here:

Link15 comments|Leave a comment

Ideas and Documentation [Dec. 5th, 2007|10:36 pm]
distributed blogs


I'd like to propose storing some kind of compiled document with summarized description of dblogs approach in source code repository. Use current blog for related items discussion and periodically issue the document containing current state of the project.

Also some set of tags should be determined. As far as this post is related to an internal d_blogs organisation, I put tag "d_blogs" here.
Link1 comment|Leave a comment

Duplicates [Dec. 5th, 2007|08:53 pm]
distributed blogs

A story of my life: the moment I get comfortable working on an idea, I discover someone else has been working on it for eons. Here's a community that was there before us: f2f_blogs. Perhaps, some sort of unification is due? What do you say?...
Link6 comments|Leave a comment

Project hosting [Dec. 5th, 2007|08:45 pm]
distributed blogs

Courtesy of Google:


(And do not ask me why not sourceforge: I guess I'm THE stupid blond, because it took me half an hour of irritation till I finally gave up on the idea of creating a project on that hideous site. I used it often before, but this was the first - and LAST, mind you! time I tried creating a project there. </rant>).

I created it because I realized updating a post with changes to a design document just doesn't cut it - we need a versioning system from the get going. So there.
LinkLeave a comment

[ viewing | 10 entries back ]
[ go | earlier/later ]