Posted by & filed under Tech.

In response to Dave Winer’s post about bootstrapping a federated 140 character message system, I doodled up a spec for a hypothetical service called “F140”. I have a basic implementation of it working and am interested in hearing comments and feedback. The implementation is VERY simple and barely scratches the surface of the issues related to this sort of thing. But in the spirit of bootstrapping, please consider the F140 Proposal.

Please note, also, that this page is extracted from the running system, so ignore the links at the bottom of the document.

One Response to “Tin Can-and-String-Federated-140 Character Message Proposal”

  1. Henri Asseily

    One of the items that I’d like to improve upon is the discoverability of one’s node. You say that a unique username would most likely be a (globally unique) email address. But that’s not enough to send a message to the person, you still need to know her node’s address. I’d like to propose an additional opportunity here, one that would simplify things significantly for the end user:
    Should the username be a fully qualified domain name (FQDN), the software could automatically determine the node address(es). Furthermore, if the username is an FQDN, then if the user switches node address then there is no breakage as the sender would automatically grab the new node address.
    One of the ways to achieve this is as follows:
    Assuming an FQDN, the software should do a DNS lookup for NAPTR records on this FQDN and retrieve the “x-f140:http” NAPTR record types which would list, with an order/preference tuple, the correct node addresses for the user.

    .tel domains already do this for contact information. If you were to do a DNS lookup for NAPTR records on my own domain for example, you’d see one of the following records: 60 IN NAPTR 100 111 “u” “E2U+web:http” “!^.*$!!” .

    If I were to add a new record as follows: 60 IN NAPTR 100 115 “u” “E2U+x-f140:http” “!^.*$!!” .

    that would allow me to tell everyone that they can message me using the F140 solution using my “” username. Of course any TLD can work, not just .tel domains. And if a software provider were to propose a service to thousands of users, they could create a dynamic DNS server that would return correct NAPTR records whenever someone wanted to send a message to say

    I guess what I’m proposing is that while email addresses as usernames is a good fallback position, FQDNs are a better solution in that they provide the correct abstraction for simplicity and redundancy. And of course if one were to use a 2nd level domain (like or, one could have the identity verification on top of it ( is already an OpenID publisher for example).