How does this handle situations where there are other TXT records such as SPF (http://openspf.org/)? Doing: "dig +short artsites.ca TXT" gets my SPF record. Or is this only supposed to work for supercloud.org?
dave
· 3 months ago
Sigh. I put it up so we could start to have a discussion about it.
And so I could learn more.
GeoffreyMeredith
· 3 months ago
You could add some similar to SPF in the TXT record and have a "v=rss http://scripting.com/rss.xml". That would require more parsing of the TXT string and having to deal with potentially multiple TXT records.
Tommy Jones
· 3 months ago
If the TXT record is stored as described in DNS-SD, then the RSS record and SPF record will not be confused.
DNS-SD stands for "DNS Service Discovery". It's a general way to find all kinds of services associated with a DNS name.
andrewtj
· 3 months ago
DNS-SD as method of finding a persons public services could be quite cool. For those not familiar DNS-SD uses PTR, SRV and TXT records to advertise services. To find services you look for PTR records name _servicetype._protocol.domain. So to find all the HTTP services associated with me you could look up _http._tcp.andrewtj.com. which might give you something like the following:
Under DNS-SD only the target and port from the SRV record are used, in this case — andrewtj.com on port 80. The TXT record contains key=value pairs which are service-specific. In the case of _http._tcp., 'u' and 'p' have been defined for use as username and password key names along with 'path' for the path. The end result: http://andrewtj.com:80/rss.xml
More information on DNS-SD can be found at dns-sd.org.
Disclosure: I'm building a DNS-SD Firefox extension (bonjourfoxy.net) and a DNS-SD hosting service (globalhostname.com) so I happen to think DNS-SD is kinda neat ;)
dave
· 3 months ago
Thanks for the info and especiallly thanks for the disclosure. Everyone who pitches some product, service or protocol should say what interest they have in it, or say they have none if they have none. So seriously thanks.
Tommy Jones
· 3 months ago
Note that a DNS host does not need to have specific support for DNS-SD as long as the host supports SRV, TXT and PTR records. DNS-SD does not define anything new at the DNS layer, but instead describes how to use existing DNS features as a service discovery mechanism.
andrewtj
· 3 months ago
On a bit of a tangent, that raises what could be an interesting side-effect. The major client-side implementations (Apple Bonjour and Avahi) implement multicast DNS for advertising services to the local network using the "local." namespace. With an appropriately enabled reader it would in-effect be a primitive form of location-based discovery.
Henri Asseily
· 3 months ago
Hi Tommy, why not use NAPTR instead (or in addition)? I just published a post explaining why I think NAPTR is much better than TXT for this: http://rikkles.blogspot.com/2009/09/rsscloud.html Essentially, NAPTR gives the following advantages: - service type and protocol - order and preference - regex replacement (not just mapping)
NAPTR works on any TLD as well. I'd be interested to know your thoughts as to the relative advantages of DNS-SD and NAPTR.
And my own Disclosure: I work with Telnic, the registry for .tel. .tel domains extensively use NAPTR records for discovery of communication channels (any URIs, essentially)
Tommy Jones
· 3 months ago
Do popular DNS hosts support NAPTR record configuration? I didn't see support at the DNS host that I use.
Stéphane Bortzmeyer
· 3 months ago
A possible solution would be to create a new DNS Resource Record Type instead of reusing TXT once again.
This is the approach favored by IAB, in RFC 5507, "Design Choices When Expanding DNS"
rbonini
· 3 months ago
Ok dave. This, in theory is pretty cool. However, what are the practical applications of this??? Whats the difference between going to username.rsscloud.org and then going to twitter.com/username or going straight to twitter.com/username.
Or are you planning to use it as a directory for all the URL's your twitter feed lives at???
dave
· 3 months ago
Okay rbonini. :-)
I don't know what the practical applications are of this.
I put it up so we could start to have a discussion about it.
I tried every way I could to say it's experimental and a proof-of-concept.
rbonini
· 3 months ago
Don't get me wrong Dave. I think its a great idea.
A few people working on OpenFF have indeed floated the DNS idea for use in distributed social networking. This is proof that the concept works.
There's been alot of chater lately ( from you included) around the idea of backing up your twitter stream to more than one place so that in the moderately likely senario of twitter.com going down, you can continue tweeting. This DNS concept of yours can be used to store all those places under one URL. :)
jeremy
· 3 months ago
The practical applications are pretty clear to me.
You can store your feed in a TXT record under a domain name. If you move from 140char Client1 to 140char Client2, you can change your TXT record from feed1 to feed2 and the aggregators that are paying attention won't be required to notice the change. They'll just deal with it. You can change services without your friends having to follow around manually.
As for handling situations where other TXT records exist under that domain... It's up to the aggregator to know what a feed is/isn't and if it is/isn't cloud enabled. We'll just grab them and check.
rbonini
· 3 months ago
Great idea. You get to keep your SEO juice as well.
connectme360
· 3 months ago
Hi Dave, I followed the instructions and received the message:
I'm working on plumbing issues for RSS. I'm looking for ways to get a GNIP-type experience to ensure the delivery of the latest RSS feeds.
jeremy
· 3 months ago
It doesn't make a website or redirect to your feed, it only adds a DNS TXT record for the feed specified.
Once you have this, an application that is looking for TXT records will know how to translate connectme.supercloud.org to whatever feed is stored as TXT.
dave
· 3 months ago
Everyone expects to be able to resolve it in the browser, I understand that DNS isn't set up to do this, that a domain can't redirect to a specific URL but people expect it to.
dave
· 3 months ago
BTW, it's not at all impossible to have dave.supercloud.org redirect to my feed, even if it's just a TXT record, without doing anything horrible. The DNS would return the same IP address for all *.supercloud.org hosts, where the web server would look up the host's TXT record and redirect to it. Nicely loosely coupled, no hacks, it should work.
jeremy
· 3 months ago
I like that idea, hadn't thought of a combo deal. :)
Anything where the user only needs to know one thing (their address) and the technology (browser/cloud app) figures the rest out seamless is a good way to start.
dave
· 3 months ago
What I like about it is that it's connecting up the lizard brain -- DNS with the cerebral cortex -- HTTP. They're at opposite ends of the evolutionary spectrum, but they're still a nice way to integrate them.
brianjesse
· 3 months ago
that's how I designed my rssCloud Rest/DNS server.. when you make a new zone like supercloud.org, it puts an A record there at the top level and then starts pumping out new TXT records for the subdomains
1. I still don't understand where this is going in terms of a namespace - *.rsscloud.org (a folly), domain.tld (less simple, not practical for vast majority of domain owners), or .tel as I argue for, but maybe you don't know either and this is just a learning exercise for you?
2. Why TXT and not NAPTR?
3. I suggest we could use different enumservice types for RSS feeds and OPML, i.e. x-rss and x-opml. That way aggregators could resolve andy.tel to my feed(s) and OPML reading list(s).
4. I also suggest aggregators use a convention such that they first check the root (e.g. andy.tel) for NAPTRs with the service types x-rss and x-opml. They should also check for a non-terminating NAPTR called 'rss', in which case they should also look for x-rss and x-opml NAPTRs in rss.andy.tel. The highest priority records should be used by default (root preferred), and hints provided to the user if others were found.
Edit: 6. It'd also be nice if we could do reverse lookups on feeds (useful for things like search indexers), and perhaps the <author> element could be adopted for this, e.g. <author>andy.tel</author>
Don't reinvent the wheel - .tel has simplicity, stability and interoperability with other services.
Give me a hug! :-)
dave
· 3 months ago
You say .tel was made for this -- but I don't get it. My RSS feed is not a telephone number. I don't see the connection. I think I've said that many times before, but on the chance that I didn't -- there it is.
Andy Chantrill
· 3 months ago
Who said anything about telephone numbers? You've misunderstood something.
I urge you to try out davewiner.tel (login credentials are in your inbox) and then we can discuss it.
playerx
· 3 months ago
The whole .tel TLD in my eyes is just another way for another domain registrar to get you to purchase yet another domain. The information on the .tel is just what you've chosen to share about you which points elsewhere, other domains, or methods of contact, phone, postal mail, etc.
Any capable user with a domain, using DNS, and HTTP can do what .tel does today. I'll further add, any new ccTLD or gTLD is not going to add/do anything which cannot already be done today.
dave
· 3 months ago
I just watched their presentation at DEMO 08 and I didn't get it. I mean I get it, in that I understand how DNS works, and they've got a nice web app for editing my DNS profile, but I don't see what's so special about .tel.
And there's is going be a lot of confusion about .tel and telephones.
What people think matters -- esp with a bootstrap which is clearly what .tel is. It won't be what it promises to be until we all buy into it. That's why we're getting such a sales pitch here, I think.
playerx
· 3 months ago
To some extent, I can't blame them. Everyone is just trying to make nice things out of prior art. :)
But you said it right there. "they've got a nice web app for editing my DNS profile";
So to some degree they just lowered another barrier for people who do not/cannot/will not run their own Internet enabled vCard and they also just happened to have the right amount of money for ICANN to bless them with control over a TLD.
dave
· 3 months ago
We're doing all this work, in part, to stop working for Twitter-the-Company, at least I am. I'm so fed up with these business models that have a line that says Over Here You Are And You Don't Get Paid and Over Here Are We and We Make Huge Money. Fuck it. If I'm going to make nothing I'll do it where no one makes anything. Telnic looks like Twitter except they don't have the critical mass. What are they offering us other than free use of their TLD. I paid $10 for supercloud.org. Okay that's a nice deal. I get $10 and...?
Andy Chantrill
· 3 months ago
The management interface is just one part of it, what about the fact there is a working specification, common APIs for TelHosting nameservers and the data consuming clients, a key brokerage for encrypted records, and as a bonus a consistent representation of records on the web. There's probably other stuff I've missed, but you get the picture.
.tel names are self-evident and can be recognised for their purpose. Whether you think the suffix means telecommunication, telephone, or telegram.. it doesn't seem important enough to matter to me. As was said elsewhere, it could be quietly dropped within an rsscloud context anyway.
You're right that new TLDs require vast amounts of money to create; there's an application fee, operational costs and even cash reserves to consider (ICANN DEMANDS stability, obviously). Oh, and you'd also need a great deal of tenacity (the original application for .tel was submitted in 2000).
If you resent the fact that all of this costs you around 10 bucks a year then I'd say everything has a cost built in somewhere. In this case it's probably a good thing that it's on the front end. I own my .tel domain and all the data within it, I can take it anywhere I like and I don't have to rely upon some third party, whether it be a behemoth or just some guy. That matters.
I haven't thought this through at all but at least for now and just for kicks I'm going to do a regex on my rss cloud client posts to find @username. Then I do the DNS lookup and if it returns a feed I rewrite the @username as a link to the feed.
Just for fun for now at least and since it's about ten minutes worth of work.
mterenzio
· 3 months ago
Or maybe make @username link to the channel <link> element value, but that has a bit of overhead to get the feed so I don't know about that. One last option could be linking to a page within my implementation that displays the feed items and shows a subscribe button since that is what a user of the client would most likely want. (I think)
At a high level, WebFinger can be used to map "user@domain" do a document describing the user. The document can link to just about anything, so WebFinger can be used to find the user's rss feed, avatar image and other user metadata that might be useful in the 140 char network.
FredDavis
· 3 months ago
Hmmmm... got an error msg: "We couldn't read your feed, or it isn't valid XML." Twitter Fail Whale?
Doh! thanks for the correction... haven't had enough coffee yet! Trying to re-invent myself as a morning person (kid in middle school) and that's fighting decades of late-nightism ;-)
Dean Michael Berris
· 3 months ago
Hey Dave, are TXT records cached just like the A's and CNAME entries? And besides, this means application specific knowledge for fetching TXT records -- hardly something browsers right now support. Cool idea still.
dave
· 3 months ago
It's not for browsers, it's for aggregators.
Dean Michael Berris
· 3 months ago
Right, but why not treat your browser as an aggregator? Do you know if there's a way to get this in JavaScript?
All Comments
And so I could learn more.
DNS-SD stands for "DNS Service Discovery". It's a general way to find all kinds of services associated with a DNS name.
_http._tcp.andrewtj.com. PTR AndrewTJ's\032RSS\032Feed
_http._tcp.andrewtj.com. PTR AndrewTJ's\032FriendFeed
_http._tcp.andrewtj.com. PTR AndrewTJ's\032Twitter
\032 is how a space is encoded in a DNS name so the above would display a list like:
AndrewTJ's RSS Feed
AndrewTJ's FriendFeed
AndrewTJ's Twitter
Subtypes of services are also catered for - if you were just after RSS only you could look up _rss._sub._http._tcp.andrewtj.com, eg:
_rss._sub._http._tcp.andrewtj.com. PTR AndrewTJ's\032RSS\032Feed
To then resolve the service you grab the TXT and SRV records the PTR points to:
AndrewTJ's\032RSS\032Feed._http._tcp.andrewtj.com. SRV 0 0 80 andrewtj.com.
AndrewTJ's\032RSS\032Feed._http._tcp.andrewtj.com. TXT path=/rss.xml
Under DNS-SD only the target and port from the SRV record are used, in this case — andrewtj.com on port 80. The TXT record contains key=value pairs which are service-specific. In the case of _http._tcp., 'u' and 'p' have been defined for use as username and password key names along with 'path' for the path. The end result: http://andrewtj.com:80/rss.xml
More information on DNS-SD can be found at dns-sd.org.
Disclosure: I'm building a DNS-SD Firefox extension (bonjourfoxy.net) and a DNS-SD hosting service (globalhostname.com) so I happen to think DNS-SD is kinda neat ;)
I just published a post explaining why I think NAPTR is much better than TXT for this: http://rikkles.blogspot.com/2009/09/rsscloud.html
Essentially, NAPTR gives the following advantages:
- service type and protocol
- order and preference
- regex replacement (not just mapping)
NAPTR works on any TLD as well.
I'd be interested to know your thoughts as to the relative advantages of DNS-SD and NAPTR.
And my own Disclosure: I work with Telnic, the registry for .tel. .tel domains extensively use NAPTR records for discovery of communication channels (any URIs, essentially)
This is the approach favored by IAB, in RFC 5507, "Design Choices When Expanding DNS"
Or are you planning to use it as a directory for all the URL's your twitter feed lives at???
I don't know what the practical applications are of this.
I put it up so we could start to have a discussion about it.
I tried every way I could to say it's experimental and a proof-of-concept.
A few people working on OpenFF have indeed floated the DNS idea for use in distributed social networking. This is proof that the concept works.
There's been alot of chater lately ( from you included) around the idea of backing up your twitter stream to more than one place so that in the moderately likely senario of twitter.com going down, you can continue tweeting. This DNS concept of yours can be used to store all those places under one URL. :)
You can store your feed in a TXT record under a domain name. If you move from 140char Client1 to 140char Client2, you can change your TXT record from feed1 to feed2 and the aggregators that are paying attention won't be required to notice the change. They'll just deal with it. You can change services without your friends having to follow around manually.
As for handling situations where other TXT records exist under that domain... It's up to the aggregator to know what a feed is/isn't and if it is/isn't cloud enabled. We'll just grab them and check.
"It worked. The sub-domain connectme.supercloud.org now maps to http://twitter.com/statuses/friends_timeline/61...
Now...when I try to visit http://connectme.supercloud.org I get a 404 message.
I'm working on plumbing issues for RSS. I'm looking for ways to get a GNIP-type experience to ensure the delivery of the latest RSS feeds.
Once you have this, an application that is looking for TXT records will know how to translate connectme.supercloud.org to whatever feed is stored as TXT.
that DNS isn't set up to do this, that a domain can't redirect to a
specific URL but people expect it to.
Anything where the user only needs to know one thing (their address) and the technology (browser/cloud app) figures the rest out seamless is a good way to start.
2. Why TXT and not NAPTR?
3. I suggest we could use different enumservice types for RSS feeds and OPML, i.e. x-rss and x-opml. That way aggregators could resolve andy.tel to my feed(s) and OPML reading list(s).
4. I also suggest aggregators use a convention such that they first check the root (e.g. andy.tel) for NAPTRs with the service types x-rss and x-opml. They should also check for a non-terminating NAPTR called 'rss', in which case they should also look for x-rss and x-opml NAPTRs in rss.andy.tel. The highest priority records should be used by default (root preferred), and hints provided to the user if others were found.
5. "Social networking federation: why not use .tel?" http://community.zdnet.co.uk/blog/0,1000000567,...
Edit: 6. It'd also be nice if we could do reverse lookups on feeds (useful for things like search indexers), and perhaps the <author> element could be adopted for this, e.g. <author>andy.tel</author>
Don't reinvent the wheel - .tel has simplicity, stability and interoperability with other services.
Give me a hug! :-)
not a telephone number. I don't see the connection. I think I've said
that many times before, but on the chance that I didn't -- there it
is.
I urge you to try out davewiner.tel (login credentials are in your inbox) and then we can discuss it.
The information on the .tel is just what you've chosen to share about you which points elsewhere, other domains, or methods of contact, phone, postal mail, etc.
Any capable user with a domain, using DNS, and HTTP can do what .tel does today.
I'll further add, any new ccTLD or gTLD is not going to add/do anything which cannot already be done today.
mean I get it, in that I understand how DNS works, and they've got a
nice web app for editing my DNS profile, but I don't see what's so
special about .tel.
And there's is going be a lot of confusion about .tel and telephones.
What people think matters -- esp with a bootstrap which is clearly
what .tel is. It won't be what it promises to be until we all buy into
it. That's why we're getting such a sales pitch here, I think.
Everyone is just trying to make nice things out of prior art. :)
But you said it right there. "they've got a nice web app for editing my DNS profile";
So to some degree they just lowered another barrier for people who do not/cannot/will not run their own Internet enabled vCard and they also just happened to have the right amount of money for ICANN to bless them with control over a TLD.
.tel names are self-evident and can be recognised for their purpose. Whether you think the suffix means telecommunication, telephone, or telegram.. it doesn't seem important enough to matter to me. As was said elsewhere, it could be quietly dropped within an rsscloud context anyway.
You're right that new TLDs require vast amounts of money to create; there's an application fee, operational costs and even cash reserves to consider (ICANN DEMANDS stability, obviously). Oh, and you'd also need a great deal of tenacity (the original application for .tel was submitted in 2000).
If you resent the fact that all of this costs you around 10 bucks a year then I'd say everything has a cost built in somewhere. In this case it's probably a good thing that it's on the front end. I own my .tel domain and all the data within it, I can take it anywhere I like and I don't have to rely upon some third party, whether it be a behemoth or just some guy. That matters.
I'm re-reading 'Another brick in the cloud' in which a solution was invited and the "fight for every inch" [for simplicity] mantra uttered:
http://www.scripting.com/stories/2009/08/06/ano...
I guess I was the one who misunderstood :-)
Just for fun for now at least and since it's about ten minutes worth of work.
At a high level, WebFinger can be used to map "user@domain" do a document describing the user. The document can link to just about anything, so WebFinger can be used to find the user's rss feed, avatar image and other user metadata that might be useful in the 140 char network.
http://twitter.com/statuses/user_timeline/14270...
re-invent myself as a morning person (kid in middle school) and that's
fighting decades of late-nightism ;-)