Scripting News - Latest Comments in Another brick in the cloud (Scripting News)

Re: Another brick in the cloud (Scripting News)

nothingmuch — Sat, 15 Aug 2009 23:30:20 -0000

for the record, nothing on that page adds any credibility to what I said.

Re: Another brick in the cloud (Scripting News)

nothingmuch — Sat, 15 Aug 2009 23:21:27 -0000

I didn't say you were conspiring to invent something new, I implied that it looks to me like you are accidentally inventing something new.

I guess for the benefit of this discussion (or lack thereof) I will invoke godwin's law by comparing myself to a nazi and just let sleeping dogs lie.

Re: Another brick in the cloud (Scripting News)

nothingmuch — Sat, 15 Aug 2009 23:17:51 -0000

Not in the formal sense, but an adhoc way of resolving short names by means of an identity service is a protocol.

My understanding is that rssCloud is supposed to be fairly decentralized, and it seems to me like a central identity server is a single point of failure.

Having addressing which easily fits in 140 characters is simply impossible to do in a decentralized way.

Email addresses are a little longer than short handles, but still fit in 140 characters pretty well, and at least theoretically can be resolved using WebFinger.

Homepage URIs are probably a little more cumbersome, but could still work.

An alternative solution would be to declare handles in the feeds, resolving the names from 140 character messages into a URL without referring to some external resource. @jason in the actual messages would only have a semantic meaning if some metadata on the feed in which it was found would explain what that string resolves to statically.

Re: Another brick in the cloud (Scripting News)

dave — Sat, 15 Aug 2009 23:16:24 -0000

Look, go read the thread here, you'll see you're wrong about anyone here
wanting to invent anything new. The time for that is long past.

If this WebFinger thing can be applied to what we're doing and if it makes
sense, then we'll use it. It's that simple. I just want to use a
loosely-coupled network.

Geeks always see conspiracies when there are none. Just relax and take
things at face value and you'll get it.

Re: Another brick in the cloud (Scripting News)

dave — Sat, 15 Aug 2009 23:14:18 -0000

http://nothingmuch.woobling...

Re: Another brick in the cloud (Scripting News)

nothingmuch — Sat, 15 Aug 2009 23:13:31 -0000

It says so on my homepage, but I don't see how that's relevant.

Re: Another brick in the cloud (Scripting News)

dave — Sat, 15 Aug 2009 23:11:23 -0000

Didn't know this person was on Twitter. What's his or her name? Any clue who
he or she works for?

Re: Another brick in the cloud (Scripting News)

dave — Sat, 15 Aug 2009 23:10:14 -0000

It's funny that you should say we're trying to establish a new protocol --
when absolutely nothing of the sort is happening. :-)

Re: Another brick in the cloud (Scripting News)

Jonathan Rockway — Sat, 15 Aug 2009 23:01:26 -0000

You could look at "nothingmuch" on Twitter to figure out who he is... or, you know, click his name.

Re: Another brick in the cloud (Scripting News)

nothingmuch — Sat, 15 Aug 2009 22:41:13 -0000

I'm no one in particular, and I'm not trying to introduce politics, it just sort of saddens me to see that you're trying to establish a new protocol when these same efforts are underway in many other places simultaneously, so I'm trying to point out the problems I saw and alternatives, that's all.

If my understanding is correct the purpose of the project is not to provide a new identity resolution system, but would benefit from one for the sake of simplicity. I don't think creating a new mechanism is the simplest solution, and you're more than welcome to ignore my opinion of course.

Re: Another brick in the cloud (Scripting News)

dave — Sat, 15 Aug 2009 22:25:15 -0000

Could you please introduce yourself?

You're bringing a lot of politics with you -- I think we have a right to
know who you are.

Re: Another brick in the cloud (Scripting News)

nothingmuch — Sat, 15 Aug 2009 22:21:55 -0000

FWIW WebFinger is based on DNS but at least it's not an NIH thing, your participation could help it get adopted

Re: Another brick in the cloud (Scripting News)

nothingmuch — Sat, 15 Aug 2009 22:12:06 -0000

The URL you're talking about is the result of some other resolution that you'd like to have.

My point is that to resolve that URL you need to use another URL, or a central naming authority.

"jason" is not sufficient to find the URL that you need for the software, and introducing a new naming scheme is the only real way to do it. DNS TXT records, etc are cumbersome for the end user. Delegating to twitter is the same thing but adhoc. Using your own identity server introduces infrastructure and more registration. All that's left is reusing existing resolution protocols (URLs and email), i think if you take into account the full stack it can't get much simpler, otherwise OpenID would be ubiquitous (it suffers from exactly the same problem).

Re: Another brick in the cloud (Scripting News)

dave — Sat, 15 Aug 2009 22:04:19 -0000

We know what the URL points to -- an RSS 2.0 file with a <cloud> element.

Too much generality is impossible to implement. For the network we want to
build RSS 2.0 with <cloud> is necessary and sufficient.

That's how you get things to be "really simple" and not "architecture
astronautics."

http://www.google.com/searc...

Dave

Re: Another brick in the cloud (Scripting News)

nothingmuch — Sat, 15 Aug 2009 21:57:29 -0000

It *can't* work without a central authority.

Even DNS is just an approximation of a decentralized network, it uses delegation and redundancy, and relies on a high latency (root servers don't change often) to provide the appearance of a decentralized structure.

DNS does work as a bootstrap for a decentralized mechanisms, like URIs.

But that's not enough. To use a URI you need to know what it means. "jason" is not a universal resource locator, it does not tell you how. urn:jason (see http://en.wikipedia.org/wik... is not a universal resource locator either (though it may be a universal resource identifier, FSVO universal). http://random.com/jason identifies the "jason" (just a path) on the host random.com as resolved by DNS, and we know to use DNS to determine what "random.com" means because 'http:' provides that set of assumptions for us.

Precisely this rich chain of assumptions and dependencies is what makes URI space properly decentralized.

You could define a schema:jason URI mechanism, but all resolution of that resource will need to use a a resolution protocol.

I suggest you look into WebFinger to go from email identifiers to URIs, and then use Yadis or other, lighter weight discovery methods to register the URI with a service.

Re: Another brick in the cloud (Scripting News)

brentrockwood — Mon, 10 Aug 2009 07:33:02 -0000

I vote DNS. Right now, the root servers are a single point of failure, and you're going to have that no matter what -- short of a wholesale overhaul of the internet. Any other choice adds another single point of failure. One is better than two, in my opinion.

Doing something like this is not unreasonable at all. SRV records might be a decent fit.

Re: Another brick in the cloud (Scripting News)

Richard Cunningham — Sat, 08 Aug 2009 13:37:12 -0000

It seems you could already do this quite simply with the DNS system that already exists.

For example, if my username is rythie and random.com manages that. I could have address at rythie.random.com with TXT record storing any bit of text I liked such as an RSS url. Since DNS is federated, random.com would be able to be down for a day or two without anyone really being affected (as long as they don't need to update their URL)

In fact you could probably store something like all your own details that would have been in a FOAF file in DNS records and if it became popular specific non TXT type records would be created for this purpose.

Re: Another brick in the cloud (Scripting News)

asplake — Sat, 08 Aug 2009 10:41:07 -0000

#4 but with an indirection via link elements or link headers. I'd want my URL to point to something human-friendly.

Edit: What Scott said!

Re: Another brick in the cloud (Scripting News)

Scott Gamon — Sat, 08 Aug 2009 05:56:44 -0000

#4 is clever, and has the virtue of working immediately. However, would it not be better if it pointed either to a rss file, or to an html page with a link element that points to the rss file? Much like rss autodiscovery?

Re: Another brick in the cloud (Scripting News)

paulmwatson — Fri, 07 Aug 2009 05:51:02 -0000

Is there much wrong with using the email format? paulmwatson@twitter.com, davewiner@twitter.com, bob@myown140.com etc.

Might even be possible that you can type @davewiner and depending on your established social-graph (follows) it resolves to davewiner@twitter.com or davewiner@rsscloud.org.

Re: Another brick in the cloud (Scripting News)

dave — Thu, 06 Aug 2009 20:37:33 -0000

I have a feeling this is going to be an endless discussion. After you figure
it out there will be an someone else who will want me to debate them on
this. So I'm going to decline. I have laid out what I think is required. If
you can put together a service that does that -- I'll test it, and if it
works, great. If not, we'll keep trying.

Re: Another brick in the cloud (Scripting News)

Josh Fraser — Thu, 06 Aug 2009 20:01:53 -0000

Full URL's seem like the best way to keep things truly decentralized, but I understand your goal of short and simple usernames.

Could we use aliases? For example, I could put my feed at http://www.joshfraser.com/s... and include an alias field in my RSS called "joshfraz". Clients could store my alias enabling you to message @joshfraz, even though the full url is actually used behind the scenes. If you are following me, you would use my alias, otherwise you would use the full URL. There might be issues with collisions on the client side since there's no way to enforce global uniqueness, but we could address that by reverting to the full URL in those rare cases.

I admit it's not a perfect solution, but I'm throwing it out there anyway as an alternative way of thinking about things.

Re: Another brick in the cloud (Scripting News)

Mason Lee — Thu, 06 Aug 2009 19:56:28 -0000

Since neither of us ultimately want to see OpenID URLs in tweets because they are too long (see http://masonlee.wordpress.c..., then we need a centralized registrar for the short names. XRI foundation and I-Names exists for this already.

My suggestion for using OpenID urls above is just a compatible (and free) intermediate solution, proving that Yadis works for this. Yadis and XRDS is invisible to the end user.

Ultimately we'd set up an I-Names broker that lets you register an I-Name and specify your rssCloud. Advantage of this approach is that other people could also provide the same service-- it's not re-inventing the wheel.

What part about it don't you like? For me, it's the price of I-Names.

Re: Another brick in the cloud (Scripting News)

dave — Thu, 06 Aug 2009 19:27:27 -0000

I don't care for this approach Mason. I was pretty clear about that. Hope
you don't expect me to go for this, cause you'll be disappointed.

Re: Another brick in the cloud (Scripting News)

Mason Lee — Thu, 06 Aug 2009 19:20:24 -0000

Okay, I've contacted the I-Names people to see if there are any I-Names providers that already allow you to customize your XRDS. I wrote Chris Messina to see if he knows of existing OpenID providers that allow you to customize your XRDS.

If there isn't anything up already, I'll see about putting one up. (On my way to girlfriend's birthday dinner now--sorry :) )

But the end user interface would be easy:

"Choose a username.
Make your password.
Edit your rssCloud URL.

Done! Your rssCloud friendly OpenID is now "openidhost://username". Log in at any time to change your rssCloud URL."