PSYC1 Federation Style
Solid: Paranoid DNS
Solid: Dynamic DNS
DynDNS on your own domain name
How to configure dynamic DNS on your own domain name? Like this:
home.iswherethestuff.is. 44 IN CNAME example.homelinux.org.
44 is a particularely short TTL (time to live).
Liquid: DNS SRV in use
When a PSYC uniform has to be mapped to a host and port pair and no port is given in the uniform, a DNS SRV lookup SHOULD be performed to retrieve the real host and port number. The lookup is performed on _psyc._tcp.hostname (See also: RFC2782).
NOTE: The DNS SRV lookup SHOULD NOT return more than one host:port pair, as PSYC currently does not support mapping of hostnames to multiple IPs. Multiple hostnames of a PSYC node SHOULD NOT resolve to multiple ip:port combinations. These things have to be taken care of by the administrators of the PSYC nodes at the moment.
When UDP is selected as a transport, _psyc._udp.hostname MAY be consulted.
The resulting IP number and port of the resolution process may point to an already existing circuit. That circuit SHOULD be reused. If the root of the uniform hasn't already been verified as being a valid _target for that circuit, a _request_authorization is necessary.
SRV lookup may be circumvented by the user by allowing him to override the physical host and port numbers explicitly. This is different from restricting the user to provide a different uniform containing the port number.
A minimal application MAY leave out DNS resolution altogether, if the implications are understood and accepted. Best practice for SRV usage in 2008 is to support it in all PSYC applications, but to not deploy SRV usage in actual installations, if possible.
Try to support DNS SRV lookup, but avoid using it since there are still some platforms and applications that cannot easily implement SRV (like psyced on windows, or PSYC clients in Flash). This will change in the long term, but for now appended port numbers are safer.
Liquid: Using DNS as a directory service for PSYC
Vapor: DynDNS by certificate
tjgillies suggested we could be running our own dynamic DNS service, so we can provide psyced installers which will automatically install dynamic hostnames if the administrator doesn't have one of her own.
lynX went on to think that such a dynamic DNS service could be controlled by TLS-PSYC circuits. You just configure your desired hostname within our dyn.psyced.org domain, then send an update request to psyced.org which will authenticate you by your server's certificate or self-signed public key. First time you use it, psyced.org stores your certificate for that hostname - next time it serves you the desired hostname only if you still have that certificate.
PSYC2: Addressing by public key
A fundamental new paradigm in communication software design as implemented by all pseudonymous systems is the idea that the recipient's public key is itself the address, so there can be no misunderstanding and no spoofing.
This is typically done by looking up the public key in a distributed hashtable. In the case of Tor Hidden Services the fingerprint is used and mapped to a pseudo domain name ending in .onion
A DHT can be seen or used as a generalized form of domain name system, only it isn't as established and omnipresent as DNS. In fact somebody has to run the DHT, which is not an appealing job. Usually nodes that participate in a P2P network also provide DHT functionality unless bandwidth or other restrictions do not recommend it. In the case of Tor for example, dedicated heterogeneous servers deliver the job, making Tor routers particularely lightweight.
Liquid: Resolution by Tor Hidden Services
As usual Tor hands out a very simple way to switch from traditional DNS to key addressing by DHT: Simply set up a hidden service and use its onion address. That is what psyced is currently trying to upgrade to. No need to run traditional federation at all. PSYC upgrades to Tor, then figures out GNUnet next:
Liquid: Resolution by GNS
But given we have a DHT, a resolution system could allow for any string to be a search item that resolves to a public key and a choice of current IP services. Since in our world you cannot own a word, other people may also be allocating that word. The DHT would store as many matches for any word or word combinations as people want to allocate, thus when you look for "news" you are likely to get plenty of keys while if you tell your customers to lookup "tom's hairdryer" only a spammer may intentionally want to collide with that. Your customers will be prompted with a choice of services and public keys. If the public key is also printed on the piece of paper they are holding in their hands they can pick the correct one and start cryptographically secured communications. Even better if they can just hold the card in front of the webcam and the software finds a public key in a QR code.
Vapor: Social resolution by GNS
Social networking: One of the key jobs of such a look-up DHT must also be to replace Facebook's ability to find long lost old friends. FB does it by suggesting people should use their real name and surname, so depending on the uniqueness of that name you have half a chance of finding her using the search box and a centralistic database. You can also search by e-mail address of course. In DHT-based thinking the person should allocate her email and former email addresses and several combinations of the <realname,birthdate> tuple so that people can find you if they know your name and year of birth, or your name and birthday without the year, or just your name and maiden name. Enough for people from high school days to find you. Your registration app would have to guide you through a good set of combinations worth registering. I suppose entries need to be refreshed on some weekly basis to avoid the DHT from getting messed up with old invalid data. Luckily GNS is really good at handling the privacy for these use cases.
Which other DHT-based resolution schemes have been written out in detail or are actually implemented and in use?