Scripting News: Another brick in the cloud (Scripting News)
Mason Lee
· 4 months ago
Have you seen http://en.wikipedia.org/wiki/Yadis ? Adopting this would let us use both OpenIDs and I-Names as the user namespace. OpenIDs are nice and short and Twitter-like (e.g. =masonlee). Anyway, the I-Name or OpenID resolves to a URL that can return XRDS xml if you ask for it, and in there you can point to the rsscloud delegate for the tweet stream. Here are some existing XRDs types: http://xrdstype.net/
dave
· 4 months ago
What does that mean, in English?
I have told you what I need to make it work, above.
Does this do it? If so, what do I say to it to turn a name into the URL of an RSS feed?
Mason Lee
· 4 months ago
Sorry, my English is not so good. :)
As no Yadis providers know about rssCloud yet, there's nothing you can say to them at present to make this work.
But supposing we had a Yadis provider that did support rssCloud, you'd say "Hmm. Here's an OpenID URL, let's get the XML description of the available services for that identity. It's a simple REST request, returning XRDS XML. Once, obtained, you'd parse it looking for the rssCloud delegate URL."
(There's one more level of indirection in the case of I-Names-- it's like a weird alternate DNS lookup-- but not so weird that many OpenID2.0 logins don't already do it.)
Mason Lee
· 4 months ago
OpenID is a (mostly) decentralized identity system, with DNS and I-Names as its parallel roots. So it's your 2. and 3. above, supposing you don't mind using Yadis to lookup the rssCloud.
So to get started, make an OpenID provider that lets you specify the rssCloud url. Have people sign up there. Eventually other OpenID providers may pick up on it and return rssCloud pointers in their XRDS.
dave
· 4 months ago
I don't mind anything as long as it's easy, simple, reliable and performs well.
Set up a server and let's see the API.
Mason Lee
· 4 months ago
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."
dave
· 4 months ago
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.
Mason Lee
· 4 months ago
Since neither of us ultimately want to see OpenID URLs in tweets because they are too long (see http://masonlee.wordpress.com/2009/07/13/would-...), 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.
dave
· 4 months ago
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.
defjaf
· 4 months ago
Dave,
I admit it's aesthetically pleasing to have short names, but why not make it more like email? Twitter(ish) addresses could, instead, be the full URLs . Then, the problem becomes that they take up too much of the 140 characters. But then why not use the other capabilities you are contemplating: make "d random.com/guy.xml" or "@ random.com/guy.xml" part of the payload/attachment (e.g., you could have a <directmessage>random.com/guy.xml</directmessage> element) , rather than the body of the message? Now, you don't even really need a dns. RSS 2.0 would probably need a namespace extension for this, but I don't think it's too big a problem.
(I understand this breaks SMS posts but so does any attachment scheme, and we could still use d/@ for that case with a length penalty)
The benchmark is Twitter, and it has very nice, simple rules for usernames.
And I don't see why the loosely-coupled network shouldn't match it in simplicty.
defjaf
· 4 months ago
Hi Dave,
Yes, but twitter's simplicity is part of the problem: all of the nice and .simple usernames are already taken (and we're still not allowed to have duplicates in the dns-like system)! I can be the only ajaffe@ixperiax.ax.uk (or certainly @andrewjaffe.net) but there's no way I can be the only jaffe, or ajaffe, or ahjaffe, at the size twitter has already reached. So longer may actually be simpler (i.e., easier to understand) in this case.
Indeed, maybe the model should be email: my *client* knows nicknames, which get fully qualified into complete email addresses that I don't have to remember. The same could be true for a twitter client, rather than the twitter "routing system".
Or am I missing a subtlety here?
Andrew
p.s. I think the idea of having the addressee be part of a non-message element is a separate plus to this idea, as it claws back more of the 140 characters (and again, the client could still display this as "@name" or "d name").
GeoffreyMeredith
· 4 months ago
I like the idea of using Yadis to associate services behind a domain name or URI. In messaging, that URI would be a user's identity but we could use "screen names" to hide any complexity in the message. This does make it hard to just type in a usable identity directly into a 140 character Twitter like message. Could use local friends lists to look up display name and embed URI in the posting process.
Mason Lee
· 4 months ago
You can use I-Names, which are short and easy to type. They also can be resolved to Yadis.
Ken Kennedy
· 4 months ago
Yadis works, but is certainly complicated. The point of Yadis is to abstract away the notion of "a new global namespace for a particular network" completely: every new service has this same issue. Yadis tries to take a particular identifier (in their model, an URI), and by making a particular type of call to that url, you get back a hunk of info that tells you a person's IM identifier (which may not even be related to the url), VOIP connector, primary email, FOAF list, etc.) It's extensible, so you could add rssCloud as a "type".
But it's a tad complicated. *grin*
One thought is to shortcut by hard-coding your initial mappings in a email style, so guy@random.com (in the context of rssCloud) would map to random.com/guy.xml. It just would, for random.com; no exceptions. Just bolt it in. To make the messaging context more clear, you could use a prefix like status:guy@random.com (ala SIP, the VOIP protocol, that uses a similar mapping: sip:foo@bar.com).
Gives you a relatively easy way to use the sort of identifier most people expect to use (email style) to map to either a permanent OpenID url, or a temporary one if they don't have one yet. You're one step closer to Yadis at this point.
Josh Fraser
· 4 months ago
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/status 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.
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.
Scott Gamon
· 4 months ago
#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?
asplake
· 4 months ago
#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!
Richard Cunningham
· 4 months ago
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.
brentrockwood
· 4 months ago
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.
nothingmuch
· 4 months ago
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/wiki/Uniform_Resource_Name) 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.
dave
· 4 months ago
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."
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).
nothingmuch
· 4 months ago
FWIW WebFinger is based on DNS but at least it's not an NIH thing, your participation could help it get adopted
dave
· 4 months ago
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.
nothingmuch
· 4 months ago
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.
dave
· 4 months ago
It's funny that you should say we're trying to establish a new protocol -- when absolutely nothing of the sort is happening. :-)
nothingmuch
· 4 months ago
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.
Jonathan Rockway
· 4 months ago
You could look at "nothingmuch" on Twitter to figure out who he is... or, you know, click his name.
dave
· 4 months ago
Didn't know this person was on Twitter. What's his or her name? Any clue who he or she works for?
nothingmuch
· 4 months ago
It says so on my homepage, but I don't see how that's relevant.
dave
· 4 months ago
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.
nothingmuch
· 4 months ago
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.
All Comments
I have told you what I need to make it work, above.
Does this do it? If so, what do I say to it to turn a name into the URL of
an RSS feed?
As no Yadis providers know about rssCloud yet, there's nothing you can say to them at present to make this work.
But supposing we had a Yadis provider that did support rssCloud, you'd say "Hmm. Here's an OpenID URL, let's get the XML description of the available services for that identity. It's a simple REST request, returning XRDS XML. Once, obtained, you'd parse it looking for the rssCloud delegate URL."
(There's one more level of indirection in the case of I-Names-- it's like a weird alternate DNS lookup-- but not so weird that many OpenID2.0 logins don't already do it.)
So to get started, make an OpenID provider that lets you specify the rssCloud url. Have people sign up there. Eventually other OpenID providers may pick up on it and return rssCloud pointers in their XRDS.
well.
Set up a server and let's see the API.
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."
you don't expect me to go for this, cause you'll be disappointed.
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.
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.
I admit it's aesthetically pleasing to have short names, but why not make it more like email? Twitter(ish) addresses could, instead, be the full URLs . Then, the problem becomes that they take up too much of the 140 characters. But then why not use the other capabilities you are contemplating: make "d random.com/guy.xml" or "@ random.com/guy.xml" part of the payload/attachment (e.g., you could have a <directmessage>random.com/guy.xml</directmessage> element) , rather than the body of the message? Now, you don't even really need a dns. RSS 2.0 would probably need a namespace extension for this, but I don't think it's too big a problem.
(I understand this breaks SMS posts but so does any attachment scheme, and we could still use d/@ for that case with a length penalty)
http://www.youtube.com/watch?v=myyWXKeBsNk
The benchmark is Twitter, and it has very nice, simple rules for usernames.
And I don't see why the loosely-coupled network shouldn't match it in
simplicty.
Yes, but twitter's simplicity is part of the problem: all of the nice and .simple usernames are already taken (and we're still not allowed to have duplicates in the dns-like system)! I can be the only ajaffe@ixperiax.ax.uk (or certainly @andrewjaffe.net) but there's no way I can be the only jaffe, or ajaffe, or ahjaffe, at the size twitter has already reached. So longer may actually be simpler (i.e., easier to understand) in this case.
Indeed, maybe the model should be email: my *client* knows nicknames, which get fully qualified into complete email addresses that I don't have to remember. The same could be true for a twitter client, rather than the twitter "routing system".
Or am I missing a subtlety here?
Andrew
p.s. I think the idea of having the addressee be part of a non-message element is a separate plus to this idea, as it claws back more of the 140 characters (and again, the client could still display this as "@name" or "d name").
But it's a tad complicated. *grin*
One thought is to shortcut by hard-coding your initial mappings in a email style, so guy@random.com (in the context of rssCloud) would map to random.com/guy.xml. It just would, for random.com; no exceptions. Just bolt it in. To make the messaging context more clear, you could use a prefix like status:guy@random.com (ala SIP, the VOIP protocol, that uses a similar mapping: sip:foo@bar.com).
Or baby-step into whole hog Yadis-style stuff with email to ID, which Chris Messina talks about at this link:
http://factoryjoe.com/blog/2008/06/22/announcin...
Gives you a relatively easy way to use the sort of identifier most people expect to use (email style) to map to either a permanent OpenID url, or a temporary one if they don't have one yet. You're one step closer to Yadis at this point.
Could we use aliases? For example, I could put my feed at http://www.joshfraser.com/status 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.
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.
Edit: What Scott said!
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.
Doing something like this is not unreasonable at all. SRV records might be a decent fit.
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/wiki/Uniform_Resource_Name) 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.
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/search?q=architecture+ast...
Dave
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).
You're bringing a lot of politics with you -- I think we have a right to
know who you are.
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.
when absolutely nothing of the sort is happening. :-)
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.
he or she works for?
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.
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.