At this point, we are into visual semantics. One could argue [EMAIL PROTECTED] is better because it's a well-known convention for email. Others could argue that http://identi.ca/susan is more friendly for use in RSS feeds. Someone else could argue using a different convention like susan/twitter.com without an @ sign is better.
Personally I don't care either way, but I'd avoid creating something entirely new because it's an age-old problem with existing and proven mechanisms for addressing. Why re-create the wheel with some "new" identification system? The problem is simple so keep the solution simple. At its roots this is a messaging platform just like every other messaging platform out there (real-time, near real-time, etc.) which needs to address messaging routing, tracking, security, privacy, etc. The Internet is based on network layers (packets, mac addresses, IP addresses, domain names, users within domains) - the only reason to add another layer is for usability (because you are not providing more functionality). The functionality is already there and being used. If you want better searching, less chatty protocols, better tracking then you can add additional layers on top of the network stack but it always comes at a cost. Unless you of course plan to build this messaging platform on top of something besides the Internet (not likely for too many reasons to name). Hey, I'd love to put an @mom on an envelope and drop it in any U.S. post office mailbox and have that routed to my mother, but I would hate to be the U.S. post office if that was ever implemented. And if my mother lived outside the U.S., I would hate the job of the person who is required to translate mail addresses between other countries and the U.S. The biggest challenge here is everyone has to agree on it a "standard", but standards usually occur AFTER the fact, not before. Adoption first, standards second as the space matures. Naturally something that works well and is adopted quickly usually becomes the basis for a standard - people are lazy. Therefore the solution needs to be seamless or invisible and usually based on something familar. Make something complex and it won't be adopted by anyone but the most tech savvy (i.e. the people on this list). Standards driven by simplicity naturally become the most widely adopted - it's a self-fulling circle. In the battle between natural standards (e.g. think evolution) versus artificial standards (e.g. you will now use RFC 31234115 to define message length, blah blah blah because it's needed to ensure flexibility for the one day in the future where everyone will be hooked directly up into the Matrix) :-) On Thu, Jul 31, 2008 at 11:38 AM, Ralph Meijer <[EMAIL PROTECTED]>wrote: > Bob Wyman wrote: > >> On Thu, Jul 31, 2008 at 12:00 PM, Seth Fitzsimmons <[EMAIL PROTECTED]<mailto: >> [EMAIL PROTECTED]>> wrote: >> > a viewer on twitter would see a message >> > from "[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>" to "@susan", but a >> > viewer on identi.ca <http://identi.ca/> would see a message >> > from "me" to "[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>". >> >> If your Tweets/Dents were being logged to an RSS file at Identi.ca, how >> should things look in that file? The file is "dumb" and can't tell whether a >> reader is an Identi.ca user or a Twitter user... Am I correct in assuming >> that one should consider readers of the file to be "outsiders" and thus both >> names would be fully expanded with no nicknames? (e.g. a message from >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> to [EMAIL PROTECTED] <mailto: >> [EMAIL PROTECTED]>) >> > > That seems good to me. Just like it is usually discouraged to use relative > links in feeds. Also, as somebody else suggested, those nicks could instead > be marked up, to point to a JID or web page. I wouldn't use e-mail addresses > as in your example. > > Note that I think that (Atom) feeds should use the Atom threading > extensions to point to the post responded on, and that one might also use > <link rel='related'/> elements in the entry to point to related entities. > > ralphm >
