Conversation
Notices
-
@sipster: nice handle. let me know what you think, and be sure to share it with people.
Monday, 22-Sep-08 18:54:03 UTC from xmpp-
@evan "post 0.6..." ? does that mean .6 is live!? *runs to check* guess not
-
@evan I like @identi.ca/evan better.
-
@evan: the latter
-
-
@evan I prefer the URL style - it seems more extensible, and it's one less rule to remember.
-
@evan I like it. :-)
-
@evan @identi.ca/evan is a lot clearer in my opinion and less likely to be an error (e.g., Which names comes first: person or system?)
-
@evan either the former (@identi.ca/evan) or even better, the unnamed third option: evan@identi.ca (a'la smtp, xmpp)
-
@evan url, KISS comes to mind here =)
-
@evan @marjoleink I believe the only issue up in the air after BHC was what char to use, e.g. @evan/identi.ca, @evan:identi.ca, etc.
-
@evan: the second one (@person@site) seems "cleaner" and maybe a bit easier to remember than a whole URL + name
-
@kshep I don't think any existing clients support distributed replies yet. URL format didn't come up at BHC, is why I asked.
-
@evan URL pattern is also an existing standard. No need to invent a new one.
-
@evan I think the url style would be better, since I can see people delimiting replied by '@' alone.
-
@evan Would infix work, so lose the initial @ and just have an email-style evan@identi.ca? Failing that, the URL syntax is preferable.
-
@evan I'm talking about basic linkification of usernames.
-
@evan jid/email format id's would be easiest for people to remember and use
-
@evan: afforementioned
-
@evan since there is allready the url syntax on remote subbing, why not just "reuse"?
-
@evan I like @marjoleink's version better.
-
-
@evan It hasn't proved a drastic limitation with email. Or XMPP.
-
@marjoleink I agree. Two @ symbols seems like the worst of all possible options.
-
@dwd Neither of those use HTTP URLs for identity, though.
-
@evan but I think a single @ would help with parsing, use a different separator for the other bits <- eaten
-
@evan but I think a single @ would help with parsing, use a different separator for the other bits
-
@bugabundo This is why you need to use track.
-
@evan username@domain[optional path] solves that problem, no? but I don't mind @url-sans-protocol or even @url
-
@kshep They ignore the server ref. They don't assume the user is local, but they do some heuristics to figure out who it is.
-
@evan Okay, so two systems that have a strong interest in identity don't use long arbitrary HTTP URLs. So what does that tell us?
-
@evan maybe @/identi.ca/evan for remote replies, that would'nt break any code, I think
-
prepares to have to rewrite code after what he thought was a "decision" at BHC to use @evan/laconi.ca
-
@evan:identi.ca
-
@metajack I'm inclined to agree with you, my only worry is that people will be thinking it is a valid email address or JID
-
@kshep just a litte regex search and replace... :p
-
@kshep The ssh protocol also uses user@domain, not user:domain. ':' is the path separator (like '/' in JIDs)
-
@mattj nothing prevents it from being one - only by reading the SRV records will you know for sure
-
@evan how would that be easier to implement?
-
@evan: I seem to be getting 404 errors sending XMPP messages to update. Is this a known issue?
-
@marjoleink Very simply transform of @example.net/sub/foo to http://example.net/sub/foo . No special cases to worry about.
-
I like @evan:identi.ca better for disambiguation across federations but hope it gets hidden and doesn't count against already meager 140char
-
@kshep You really wrote code based on that discussion? Seems like you're getting ahead of yourself.
-
@metajack ObNitPick: ssh actually uses user@host, where host can be an IP address (or a domain or subdomain that resolves to one).
-
@evan oh, I don't like that one bit - no disambiguation by only *adding* bits to the user name that makes it resolve (most user-friendly)
-
@evan well we don't want to point to the wrong person, but we also don't want to over-complicate or over-engineer it, right?
-
@evan a user-friendly format surely is more important than a coder-friendly format? a couple of regexes will take care of it
-
For those following along on the twitter, yes @evan asks for and considers input from users/developers on identica. weird huh? :-) change.
-
@exador23 *snort* so weird I'm totally used to it - feels comfortable, in fact
-
@evan Except you're completely disregarding the norm for very little reason. I don't think these paths should be exposed to users.
-
@evan start with 1) a user-friendly syntax, 2) a production grammar for that syntax and 3) a regex derived from that production grammar
-
@marjoleink It's a logical fallacy to presume what seems obvious to the speaker is obvious to everyone.
-
@evan If writing code based on what seemed to be a consensus at BHC is "getting ahead of yourself" I think we're all in trouble.
-
@marjoleink It's the way things are supposed to work. I don't need my way, but I like to have my say.
-
@metajack "Norm"? You mean username@domain? Users on social networks and users of OpenID are familiar with URLs as identities.
-
@evan +1 to @marjoleink comments... the user experience is of high concern here...
-
@kshep My understanding was that we decided to use somethin akin to JIDs but with short circuiting resolved by dns or smart clients.
-
@exador23 agree 100% - and that's one reason why this place does feel comfortable!
-
@evan Not at all - nobody says "Here's my Twitter URL", they say "I'm foo on Twitter".
-
@evan Far more people are familiar with email. URLs are not easy to remember, and is one of the big complaints of OpenID.
-
@evan Even more so when OMB implementation might have various paths. Now i have to remember path semantics for every person i talk to?
-
@evan URL-as-identity is not the same thing as URL-as-addressing-mode; signing in with OpenID I only need to type it once
-
@kshep Rough consensus and working code.
-
@kshep This is what i suggested we start at BHC when shortname resolution came up. Although without some consensus it's going to be tough.
-
@kshep yeah, the standards body of "we're social network xyz and WE'RE going to use method z and you all must conform because we're first"
-
@metajack @evan I'm bringing up the vid of BHC Sess. 3 now. Will post the timecode of the discussion about this. http://tinyurl.com/bearhug
-
@kshep That was my understanding as well. @evan specifically stated at #bhc he did not like @http://blah
-
@evan You could register a URI schema though (once you have a grammar ;))
-
@metajack we all agree that "@address" should work, and most think that "@username@domain" looks bad. So it won't be email-like anyways.
-
-
@raster I like you /network idea, Count me as a vote for it :D
-
@evan, you know what would be cool? An optional extension no the standard Identica API that supports geographical information.
-
@marjoleink Yes I prepared them with lots of advice from my friends... I fried lots of veggies with spice and then boiled them with lentils
-
@marjoleink It's still a bit of a work in progress.. last night the chili pepper I added made it too hot to even taste!
-
@binyamin that sounds good (especially the 'spice' bit :D)
-
@binyamin I made a dish with Indonesian spices yesterday - left over for two more days ;)
-
@marjoleink I was simple with the spices/seasoning.. garlic, pepper, bay leaf, chili, salt
-
@binyamin with all that, you don't need the salt - try it, you'll taste more, not less
-
@binyamin veggies provide salt all by themselves
-
@binyamin but there's hardly a day I don't use garlic in /something/ :)
-
@marjoleink ok good advice :)
-
@evan: Following scraps of discussion about message brokers with interest. You should look at Apache Servicemix. It's not just a broker.
-
@gabe OK, I'll give it a look-see. I'd like something that supports STOMP and/or AMQP to allow some choice.
-
@evan: crmseo is spam :)
All Identi.ca content and data are available under the