[Freedombox-discuss] Friendika

Boaz alt.boaz at gmail.com
Thu Jul 14 19:25:20 UTC 2011

Standard disclaimer: non-developer's thoughts follow.

>And for those who have time to spare, I put gave a presentation on "Philosophy and the >Social Web" and the first
>philosophy and web conference last year in Paris. Though this is in English:

>If you don't want to rely on DNS then I wrote up how to do that on this list
>  http://lists.w3.org/Archives/Public/public-xg-webid/2011Mar/0068.html
>(if someone wants to play on developing httpk, let me know. I just need some help with >distibuted hash tables)

Yes, I read that post and watched that video back when you originally
posted it (and the link to the video) but at the time was just very
confused.  Watching and reading again a second time after a few months
of reflection, I understand much better.  In
I see the beginning of something awesome.

The first part rephrases, in a much more logically thorough way that I
have (and which I had a hard time understanding the last time I read),
the problem and the solution that I've been advocating all this time.

Then comes the talk of “httpk”.  Httpk, as I understand it, is a key
fingerprint, used as an address to be used for finding the owner of
that key in the network.  A completely decentralized naming system,
elegantly putting to rest any question of who is the rightful owner of
a particular name (only the owner of a certain private key can claim
the name), its only failing is that it's not at all human memorable.
There was a bit of discussion about this type of naming system a few
months back when there was a flurry of discussion about naming systems
generally (some of the thread names were: “human-meaningful names and
zooko's triangle”, “assigned numbers without ICANN”, there were
others).  I see the lack of human memorability as being not nearly so
large a drawback as it may seem.

I think of this as using the “identity key” which I speak of in the
embarrassingly long post, as a sort of address or name.

And consider the utility.  People have dynamic IP addresses, they're
behind NAT and don't even have public IP addresses, they change ISPs,
they move, and so on.  They stop paying for a domain, they switch DNS
providers, their DNS provider hands their name over to a hostile
government, and so on.  These tools, IP addresses and domain names,
are very useful tools for finding how to make a connection to a remote
host, and we should use them as such.  But they're not good tools for
identifying a particular person over the long haul, and we shouldn't
use them as such.

Consider the scenario: Bob and Alice meet at a party.  Bob gives Alice
an http url for a foaf profile.  He has a domain registered, bob.net.
After the party, Alice resolves the domain to an IP address, makes a
connection to that IP address, and is served up the page.  On it is a
key, Bob's “identity key”.  She stores this as being the defining
identifier of Bob.  She sends him a few emails, encrypted using a key
signed with that key.  A week later, she makes a SIP call to Bob.
They compare ZRTP short authentication strings, and from that point on
she feels confident that the identity key she has on file for Bob
truly belongs to the Bob she met at the party.

A year later, Bob decides he hates Verisign (or DHS seizes his
domain), and he moves to a .is domain or whatever.  Or he ceases to be
able to afford the registration fee, and gives up having a domain at
all.  Or whatever, he no longer has his old domain.  He also moves,
and his IP address changes.

No problem, ever since that very first contact, Alice hasn't been
relying on his domain to contact him; she's been using his identity
key as an identifier in httpk (or whatever it will be called).

Alice just got all the benefits of the decentralized, globally unique
identifier based on a key fingerprint, but she used the human
memorable name that Bob also happened to have at the particular time
when she first started talking with him, to find him the first time.
What a great thing.

And Henry, your idea of embedding the key-fingerprint-based name in a
valid normal http url, just makes it easier to use both systems in
conjunction and makes the deal that much sweeter.

>The disadvantage is that you may have to call all your friends either if you loose your box, >OR if you loose access to your DNS domain.

But I don't think you do in most cases.  We're envisioning that the
pure httpk url all by itself, without the traditional DNS component,
is enough to resolve to an ip address, right?  So then computers
(read: freedom boxes) should be configured to use the httpk url alone
if it has an httpk url available to use.  Read: you don't need to
notify friends when you do change domain names.

>So why are these URLs useful? Because they help us give names to what an entity says, >and makes it possible to merge statements by different people easily allowing us to create a >linked web of trust (as opposed to a signed web of trust) If I am known under a name >people can claim they know me, and I can claim to know them, but also so that I can link to >a blog posted by alice, or to her thesis, holiday pictures, etc... By using links we can grow >the size of the web from a web of signed certificates to a web of signed documents and a >web of everything in existence. This makes it much more useful, and so creates a huge >momentum.
>So for example if I get to know Alice I can add to my profile
>me a foaf:Person
>    foaf:knows <httpk://lhslkdhfsdfsdfsfsfdsxxs23sfsdf/people/Alice#me> .
>And so for anyone who knows me if they get an invitation by alice or Bob their software can >help them make the initial trust decision: their freedom box can say "Henry knows Alice, and >he took some pictures of her which you can see here and here. Does this look like the alice >you wanted to contact?". Then you get additional confirmation.

Yes, the web of trust becomes so much more workable all of a sudden.
Rather than relying on these static certificates, which one goes out
of his way to sign, and which lose their momentum if anything on them
needs to change, a more fluid approach where every statement made on
your friends' profiles (which of course you know to be authentic) can
be used as certificate information for identifying other people.  Much
more practical.

>I occurred to be that each freedom box could have a URL that lists all the public keys they >have come across for each domain:port service they came across. So my profile could state
>:me publicKeyDoc </system/keys> .
>which could than state
>[] a Service;
>   host "alice.name"
>   port 443
>   lastIPseen ""
>   publicKey aPubKey .
>[] a Service;
>   host "bblfish.net"
>   port 443
>   publicKey ...
>I suppose this would be public but need not be. The above could be a bit long though for >people with a lot of friends and a caffeinated FB... So why not link to a simple lookup service
><> securequery </system/keys?> .
>The /system/keys? page could just be a simple HTML form, with 4 fields
>host, port, public key and perhaps ip address. Fill any out and it could return an rdfa marked >up page giving an answer that is a filter of what it knows.

Wow.  In addition to every other mechanism, a sort of global fact
checking network.  I wonder how this thing could be leveraged to
improve the security of the internet in general, even for people who
don't use and have never heard of it...

>If you don't want to rely on DNS then I wrote up how to do that on this list
>  http://lists.w3.org/Archives/Public/public-xg-webid/2011Mar/0068.html
>(if someone wants to play on developing httpk, let me know. I just need some help with >distibuted hash tables)

Henry, if you're interested in developing this, drop me a line on the
list or individually so we can talk more about it.  Unfortunately, as
I've been warning at the very beginning of every post lately, I don't
yet have the know-how to give you some help with distributed hash
tables :(  But I would be happy to pour every resource that I do have
into this project.


More information about the Freedombox-discuss mailing list