Argo User Ventures

But remember, DNS is not HTTP or HTML. We still need those tools for presentation for the time being. - Don Faulkner

Getting the backend grid functioning with feature-rich abilities is for more important than the front end work in this scenario. Each front end may want a different look and feel but the transport for a distributed social network needs to be very structured and standard. - manielse (Mark Nielsen)

Exactly..... DNS is simply for name resolution. You need somthing on top of that to actually do the heavy lifting. - Roberto Bonini

DNS is for name resolution..today. But DNS is a directory, and you get out what you put in. What DNS or similar technologies can provide us with is the glue that forms the "social" in the network. It can describe my subscriptions. It can describe my content sources & feeds. - Don Faulkner

So a DNS directing people to your social profile???? or a personal DNS for all your blog posts, FF items, etc????? - Roberto Bonini

More the DNS for directing. The "personal DNS" is already here in the .tel domain (see http://www.telnic.org). What I'm suggesting has nothing to do with linking a hierarchical name to an IP address. - Don Faulkner

My ideas aren't fully thought through. My phone keeps ringing, and I do have a day job. :) but DNS seems to have a lot of the features we need. Even if we don't use DNS iteslf (I don't see yet why we shouldn't), it has features to be included in social networking protocols. - Don Faulkner

DNS isn't everything, of course. It's a database, but there still needs to be some form of publish/subscribe model and push/pull updates. We need those because I'm not equally interested in all social media users, whereas I am just about equally interested in all domain names. - Don Faulkner

This idea is completely new to me, and I don't quite get it yet, but there may be something here. Off to research DNS! - Vezquex

I promise I'll write more. Just as soon as I get the firewall working. And the new e-commerce site up. And Splunk configured, and, and, and... :) - Don Faulkner

Hi Don. The problem I was proposing to solve using DNS was the whole tiny.url legacy issues. I have a severe dislike of the URL shorteners, seems everyone is building them these days. I note Google is building one too, seems all the major companies are doing this causing massive fragmentation. I'd love to see these redirections buried as part of DNS. There are smarter people than me who understand what the real underlying challenges are, but the concept is simple enough. - Mark Aitken

"On-Demand" CNAME or TXT records? Or something similar? - Tyson Key

Mark, URL shorteners are a necessary(?) evil. We shouldn't need them because we should be able to trust the links provided by the <a> element in HTML. But, of course, we've all seen the disaster that comes from blindly clicking on a "friendly" link in an email. - Don Faulkner

Tyson, Yes. That's sort of the direction I was going. SVC records too probaly. Also, if it's our own data, we can create a new record type or types for it. DNS supports that. (TXT is fine to start). What I admire about DNS is the cacheable distributed hierarchy. Let's use that part and build on top. - Don Faulkner

It doesn't help that DNS servers are pretty slow at propagating updates, too. Although that's probably since they weren't designed to be constantly updated every few seconds (unless someone knows otherwise), and latency has a part to play. - Tyson Key

Still, it's a starting point, and not the end destination. - Tyson Key

It's certainly a starting point, nothing more. Current DNS is designed for semi-durable information (domain name A records and the like). TTL's and other factors mean propigation delays of minutes. That would have to come down into the seconds range. It could be done though. - Don Faulkner

Come to think of it, it's probably something that can be resolved, given that the folks who developed mDNS managed to create an ad-hoc, near-realtime distributed DNS system that works within LANs. I'm not sure if it would scale on the Internet at large, since it depends on multicasting, though. - Tyson Key

Good point about TTLs, though. - Tyson Key

The TTLS just need to be ramped down to seconds instead of minutes. - Don Faulkner from IM

Of course, there could be a mechanism that slowly increments or decrements them over time, dependant on how often an entry is accessed or modified. Authentication might be interesting too, given that people will depend on a short name always resolving to the same URL, and there's a potential for tampering and update race conditions. Still, if it was designed properly, there should be a unique, randomly generated ID for every "shortened" URL, which should moot some of those problems (hopefully). - Tyson Key

You'd need to cooperate with the organisations running the root servers, too, if you were to have any chance of providing the said DNS records-based system, unless someone has other ideas. - Tyson Key

Good luck getting large ISPs to cut their TTL's down. Many of them are set to weeks, not days, hours or minutes. I'm not convinced about using DNS for anything other than what it was designed for. Unless it's all going to be re-written we'll just end up with big security issues like we have with most other technologies that have been adapted for use on the "modern" internet. Using the structure or the idea as a basis for something else, that makes sense to me. - Kenton

Timesync or Universal Timestamping is an issue but I think from a presentation and delivery layer, real time TTL is something that can be improved over time. The reason why I say this is because you may want the ability to allow the ability for offline clients or Google Gears type features. - manielse (Mark Nielsen)

Kenton, I'm not suggesting that we load all this data into existing DNS. I'm suggesting that we use the protocol (or parts of it) as part of our locator, pub/sub, and other backend processes. If we were to use DNS directly, there are ways to be accommodating. "Our DNS" could be a separate service. Or, we could have a separate constellation of root servers. - Don Faulkner

Besides, TLD's are set on a zone-by-zone basis, or even for individual records. The ISP's have no control over what we set our TLD's to. - Don Faulkner

+1 Mark for bringing up time. That's important. - Don Faulkner

That makes more sense now, Don. - Tyson Key

I think I see where you are coming from Don, still not sure about it, however I'm open to the idea. As far as TTL's the problem is caching. No matter how quickly your TLD updates, if it is being cached on an ISP's server the changes aren't going to be seen by the people using that ISP. Now if your idea of using DNS as a protocol only works and you are able to avoid ISP's wanting to have a piece of the pie, then there's nothing to worry about. - Kenton

For me, the ultimate problem is decay of links which I think is more important than trusting a link. People talk about improving the search ability for Twitter, making it span months of tweets not weeks. When that happens, you will hit the shortener's. Now, if the shortener site has since passed away (and lets face it, how are they making their money), then the linkage will be gone and the web linkage fabric die with it. - Mark Aitken

Google won't be able to easily index these pages behind these short url links and pages will lower in page rank due to Google being unable to spider. That's the problem I'm ultimately pointing to. If Google can't find your linked page, does it really exist? Did the conversation context over time mean anything without the shortened links working? This prevents real time conversations being part of the historical fabric of the web, and that's sad and wrong. - Mark Aitken

Anything distributed in nature or cached will also result in some problems for real time applications. I think DNS has stood the test of time well (for a protocol of 40+ years) but todays problems require new solutions. More like p2p networks or federated networks - Mete Donmez

mark: Scoble is using it over on building34 - Roberto Bonini

Who is going to control the root DNS servers. You still have this point of failure. - Amit Morson