Ideally the namespace will be very personal. And you'll be connected peer-to-peer style.
Example: In my contacts there will simply be: debbie alias [EMAIL PROTECTED] If debbie changes to new.im, it isn't a problem. I simply update: debbie alias [EMAIL PROTECTED] I'm subscribed to a stream of information from friends. These reside in my own domain and devices. If I change domain, this ain't a problem neither. My peers are kept aware. Everyone updates: nick alias [EMAIL PROTECTED] The key concept is this: my identity is my network. This is what works in the real world. What identifies you is your friends and family. Your identity and your information is preserved. It doesn't matter if you are @iss.im, @new.im, @whatever.im You will still be just "nick" in your personal network. Best regards, Nick Vidal On Thu, Jul 31, 2008 at 4:06 PM, Dave Cridland <[EMAIL PROTECTED]> wrote: > On Thu Jul 31 18:13:47 2008, Blaine Cook wrote: > >> I'll argue that until we have said federated networks, this is a moot >> point >> (c.f., the @reply convention in twitter was, as Lachlan said, only >> codified >> once people using the service had actually used @replies. Alternative >> forms >> that were (possibly still are) accepted by twitter are "name: " and "r >> name >> "). My claim is that emergent behaviour should be observed and codified >> once >> a federated system exists, not before. >> >> >> I'll go along with that - you're essentially saying that the user-driven > syntax of replies is a property of the interface, not the protocol, so > really, whether we choose @[EMAIL PROTECTED] or [http://...] or BANANA! > BANANA! > YIMBO! PITOW! ... BANANA! (the latter being, frankly, my personal favourite > based on æsthetic reasons) matters little to the protocol. At the protocol > level, we simply need fully qualified, globally unique, names - we need to > agree on the form of those names, and how to encode them for machine > readability, but otherwise how they're formatted to the end-user has no > impact to the protocol. > > There's a thumping great impact on the interface, of course, and user > expectation will lean toward consistent interfaces, but this will, as Blaine > says, come out in the wash, and meanwhile, interface ease of use will be a > strong differentiating factor. > > I mean, sorry, lightweight semantic markups used by user interfaces to > instances of the federated microblogosphere are a clear instance of emergent > behaviour. (Do I get a prize for that many buzzwords?) > > I will point out that we should build the basics, and then expand upon >> ideas >> once we have groundwork to expand upon. All of this is pure speculation. >> > > Which is why anyone can have an opinion, even me. :-) > > No - the real problem is being able to do replies to the correct thread. >> > > Impractical, or impossible, for some interfaces, including SMS. But this is > okay, this is why we have XMPP user interfaces, and tell people to use XMPP > clients on their phones. Or email. Or whatever. > > Or, maybe there's a really clever classifier handling incoming SMS messages > and matching them up by subject material to SMS messages it's sent the user. > > Or maybe someone decides that telling users how to use a bunch of cryptic > symbols in SMS messages is going to be more fun. > > > Dave. > -- > Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]<[EMAIL > PROTECTED]> > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >
