User:Zero Linden/Office Hours/2008 September 16

From Second Life Wiki
Jump to: navigation, search
  • [13:03] Morgaine Dinova: 'Morning Tess :-)
  • [13:04] Tess Linden: 'Afternoon :)
  • [13:04] Mirt Tenk: night for Xugu
  • [13:04] Xugu Madison: Ad
  • [13:04] Morgaine Dinova: Woot! The Interoperable variety of Tess :-)
  • [13:04] Xugu Madison: and I'm totally awake at keyboard
  • [13:04] Mirt Tenk: I made a keyboard today
  • [13:04] Xugu Madison: Oh?
  • [13:05] Rex Cronon: hello everybody
  • [13:05] Xugu Madison: thanks
  • [13:05] Xugu Madison: hi Whump!
  • [13:05] Morgaine Dinova: Dahlia, you seem to be embedded in the sofa, looking from here.
  • [13:05] Zero Linden: heh
  • [13:06] Morgaine Dinova: 'Morning Zero :-)
  • [13:06] Whump Linden: Xugu, great avi.
  • [13:06] Xugu Madison: evening Zero!
  • [13:06] Dahlia Trimble: mu ao :/
  • [13:06] Whump Linden: Love the steampunk squirrel.
  • [13:06] Dahlia Trimble: hiya zero
  • [13:07] Morgaine Dinova: Hehe, cute Whump :-)
  • [13:07] Zero Linden: Ah - I see that everyone must have been exhausted from this morning's AWG
  • [13:07] Mirt Tenk: or missed it :-)
  • [13:07] Zero Linden: either that - or the grid is having TP trouble again....
  • [13:07] Dahlia Trimble: not me, I missed it ;)
  • [13:07] Goldie Katsu: points to her cup of coffee as indication of looking for second wind.
  • [13:08] Mirt Tenk: chocolate covered coffee beans are faster
  • [13:08] Dahlia Trimble: eeks
  • [13:08] Mirt Tenk: for the second wind
  • [13:08] Zero Linden: someone left the shower and bath on
  • [13:08] Zero Linden: I just turned 'em off
  • [13:08] Goldie Katsu: not quite as yummy as home roasted coffee though.
  • [13:08] Whump Linden: measures out his life in coffee cupes.
  • [13:08] Mirt Tenk: we're on water rationing
  • [13:08] Mirt Tenk: in rl
  • [13:09] Morgaine Dinova: How many coffee cups make up a Library of Congress per furlong?
  • [13:09] Mirt Tenk: is that like coffee in ice cubes Zero? coffee cupes?
  • [13:09] Mirt Tenk: you keep a frozen stash on hand?
  • [13:10] Zero Linden: actually- I got iced coffee from a great little coffee house the other day that makes the ice from coffee!
  • [13:10] Zero Linden: so nice not to have it diluted as it melts!
  • [13:10] Goldie Katsu: oh yum!
  • [13:10] Morgaine Dinova: Hehe
  • [13:10] Zero Linden: okay - well all - welcome to my office hours
  • [13:10] Zero Linden: FIRST
  • [13:10] Zero Linden: an ANNOUNCEMENT
  • [13:10] Teravus Ousley: listens
  • [13:11] Zero Linden: Saturday marked 1 year since the first AWG meeting
  • [13:11] Dahlia Trimble: how about expresso cubes?
  • [13:11] Zero Linden: In one year we've accomplished functioning login and teleport and a draft spec for same
  • [13:11] Mirt Tenk: wow congrats
  • [13:11] Zero Linden: I think we deserve a round of applause for that
  • [13:11] Dahlia Trimble: W00t!
  • [13:11] Xugu Madison: applauds the Lindens
  • [13:11] Zero Linden: applauds the AWG!
  • [13:12] Morgaine Dinova: Hehe
  • [13:12] Zero Linden: Now then
  • [13:12] Zero Linden: Agenda
  • [13:12] Goldie Katsu: yay1
  • [13:12] Zha Ewry: checks her prims for teleport scorch marks
  • [13:12] Zero Linden: 1) Summary of morning's XMPP discussion
  • [13:12] Zero Linden: others?
  • [13:12] Xugu Madison: Coffee :P
  • [13:12] Goldie Katsu: notes that Zero's second supposition seems likely
  • [13:12] Teravus Ousley: 2. Name + Domain in OGP teleport
  • [13:13] Tess Linden: zha wanted to talk about WSDL ? and service discovery?
  • [13:13] Zha Ewry: NOT WSDL
  • [13:13] Zha Ewry: eeeeeeeeeeek
  • [13:13] Teravus Ousley: 3. a way to specify location you want to teleport to in OGP?
  • [13:13] Xugu Madison: LLIDL I thought instead of WSDL?
  • [13:13] Dahlia Trimble: +1 on #3
  • [13:13] Teravus Ousley: .. ie.. we specify region domain.. but 'safe' gets always sent
  • [13:14] Zero Linden: 2) Name/Domain in OGP
  • [13:14] Zero Linden: 3) Teleport destinations
  • [13:15] Zero Linden: did anyone need WSDL on the agenda?
  • [13:15] Xugu Madison: Only if it's to burn it
  • [13:15] Teravus Ousley: like a migrane?
  • [13:15] Zero Linden: going..
  • [13:15] Zero Linden: going...
  • [13:15] Zha Ewry: Not I. Discovery is fine topic. WSDL is not how we want tosolve it
  • [13:15] Zero Linden: gone!
  • [13:15] Whump Linden: looks for holy water.
  • [13:15] Zero Linden: 1) morning XMPP summary
  • [13:15] Goldie Katsu: casts fear on the WSDL agenda item
  • [13:15] Zha Ewry: We can put estabslihgin trust between components, in a provable, cert fashion, on the longer term agenda
  • [13:16] Zero Linden: basically I heard three main things this morning
  • [13:16] Morgaine Dinova: "Why don't we use XXXX?" questions keep recurring --- the pro's and con's should be documented on wiki, and the reasons for rejection.
  • [13:17] Zero Linden: 1) Most interoperability desires for IM/Chat come from the use cases of a user connecting a standard client to their agent domain -- or an agent domain offering to exchange IM traffic with some other IM system (say, gTalk)
  • [13:17] Zero Linden: both of these cases are handled outside of OGP - as any Agent Domain could choose to do them
  • [13:17] Saijanai: Kuhn: can anyone give me the first few minutes of the transcript? Thanks
  • [13:18] Zero Linden: 2) There was thinking that existing IM servers would do better at handling some defined case of IM traffic (left undefined here for now)
  • [13:18] Zero Linden: but again, these would be internall to an agent domain --- though recognizing that *if* the OGP protocol were the same as the server's base, then the "bridge" would be null
  • [13:19] Saijanai: Kuhn: well, the data conversion bridge would be null. But aren't their other issues specific to SL-style IM/
  • [13:19] Dahlia Trimble: assuming that the AD is a preferred broker for IM rather than the client
  • [13:19] Zero Linden: 3) We could use XMPP as the underlying transport for OGP --- but HTTP is a much more widely usable transport
  • [13:20] Zero Linden: and requiring both seems like a very undue burden
  • [13:20] Teravus Ousley: why not XMPP over BOSH then..
  • [13:20] Xugu Madison: BOSH?
  • [13:20] Xugu Madison: I tend to prefer HTTP as a transport, because I've read the spec on it :-D
  • [13:20] Saijanai: Kuhn: as the primar/official form of group IM, sure. But client plugs could support any number of models, and still ask the AD to provide authentication
  • [13:21] Teravus Ousley: yeah.. [1]
  • [13:21] Zha Ewry: [2]
  • [13:21] Zha Ewry: heh
  • [13:21] Goldie Katsu: ahh
  • [13:21] Zero Linden: Well - since there is nothing inheritly special about the XMPP stanzas for messaging --- and it wouldn't actually be interoperable with existing XMPP clients ---
  • [13:22] Zero Linden: I don't see the benefit of requiring two more protocol stacks in the viewer (BOSH and XMPP -- assuming you can find an XMPP stack that can take its input via BOSH...)
  • [13:22] Xugu Madison: Looks, at first glance, like a fantastic way of consuming any spare bandwidth you might have had
  • [13:23] Saijanai: Kuhn: if we want a 2-way continuous stream, establish a client server relationship in both directiosn with 2 CAPs. one r-http and one not
  • [13:24] Zero Linden: And - frankly, BOSH looks almost exactly like the expanded event queue design we've talked about here
  • [13:24] Teravus Ousley: heh, it does indeed.
  • [13:24] Teravus Ousley: constant poll, as opposed to long poll
  • [13:25] Morgaine Dinova: If extended XMPP (extended so that we can have rich IM content) is not going to be interoperable with XMPP clients anyway, then adopting XMPP would appear to be just a noose around our necks.
  • [13:26] Saijanai: Kuhn: whch goes back to a question raised in SLDEV by someone. Does a push model work as well as a pull model? Does the current comet long-poll turn out to be more efficient for getting group IM messages than an r-http type thing?
  • [13:26] Zha Ewry: agrees
  • [13:26] Zha Ewry: Why add a format unless you got dead easy client intero from it?
  • [13:26] Zero Linden: AND frankly, in so far as BOSH expects an internal (server side) proxy to feed the stream to a XMPP server, I don't see why we couldnt' do the same with OGP
  • [13:27] Teravus Ousley: I'm not disagreeing with you. :D
  • [13:27] Saijanai: Kuhn: first few minutes of meeting in notecard plesae? About 1:16 is when I got here
  • [13:27] Zero Linden: okay - so -- I dont' 'think there were any other potential XMPP uses that were discussed
  • [13:27] Saijanai: Kuhn: 1:17
  • [13:28] Whump Linden: Fword mentioned several use cases in the transcript, but those weren't XMPP specific.
  • [13:28] Morgaine Dinova: That said ... a best-effort gateway into XMPP would definitely be a bonus.
  • [13:29] Teravus Ousley: mostly suggested it because it was an XMPP extension.. and very similar to our current system
  • [13:29] Saijanai: Kuhn: Bjorlyn mentoned an issue they're looking at with Sciene friday. 1.25 million listeners who might want to participate in gropu IM
  • [13:29] Zero Linden: heh - I'd LOVE to see any existing IM system handle that!
  • [13:30] Saijanai: Kuhn: right, but its a real situation for them
  • [13:30] Zero Linden: Okay then
  • [13:30] Saijanai: Kuhn: They'd like to bring the listeners into the SL chat in some way
  • [13:30] Dahlia Trimble: gave you New Note.
  • [13:30] Zero Linden: I have one word for them: shards
  • [13:30] Zero Linden:  :-)
  • [13:31] Teravus Ousley:  :D broken glass..
  • [13:31] Teravus Ousley: j/k
  • [13:31] Zha Ewry: Chuckle
  • [13:31] Zero Linden: okay
  • [13:31] Zero Linden: 2) Name/Domain in OGP
  • [13:31] Zero Linden: Teravus?
  • [13:31] Morgaine Dinova: Well it's not just an implementation issue. It's also a communication issue --- obviously 1m users can't communicate in a crowd session, AFAICS
  • [13:32] Morgaine Dinova: Imagine the IM scroll ....
  • [13:32] Teravus Ousley: Yes. simply put.. in OpenSimulator.. we discourage it... but it's possible to munge UUIDs to overlap with an account.. so having a domain ..in the credential info prevents that from occurring.
  • [13:32] Zero Linden: Am I right in thinking there are two issues here
  • [13:32] Teravus Ousley: .. We'd also like to potentially be able to tell the client, oops, your UUID overlaps.. use 'this' one instead
  • [13:33] Zha Ewry: That last one, is important
  • [13:33] Zha Ewry: We can detect the clash
  • [13:33] Zero Linden: a) What happens when a foriegn agent TPs in and they have the same UUID as some other agent you know about (locally, or from somewhere else)
  • [13:33] Zha Ewry: it would be nice if would hsndle it
  • [13:33] Zero Linden: b) How do we identify avatars to users if they have the same name?
  • [13:33] Zha Ewry: *we could handle
  • [13:33] Whump Linden: Would this be a modification to rez_avatar/request
  • [13:34] Teravus Ousley: Yes, this would be in the request and the response to the request..
  • [13:34] Zero Linden: well - or just assign them all local UUIDs
  • [13:34] Xugu Madison: Identifying between two with the same name... a "You have talked to this person n times" count?
  • [13:34] Xugu Madison: and/or "you last talked to them on <date>"
  • [13:34] Teravus Ousley: in the request, it would include an ID for an agent domain
  • [13:34] Teravus Ousley: .. in addition to the user's credentials
  • [13:34] Zha Ewry: the problem with locla, is that the client will choke, and.. we realy, really don't want to have someone's UUID change as we do turst downt he road
  • [13:35] Zha Ewry: uuid isn't enough to anchor trust on anyway
  • [13:35] Morgaine Dinova: You mean common name overlap, surely, not UUID overlap. UUIDs are unique, assuming your random function works, no?
  • [13:35] Zha Ewry: But. it's par tof thr problem
  • [13:35] Teravus Ousley: .. and in the response, it would contain the 'Use this UUID in the UseCircuitCode packet'
  • [13:35] Zha Ewry: Only statusically, Morgaine
  • [13:35] Xugu Madison: I think on UUID clash you have to reject the incoming avatar as coming from a damaged UUID generator, and leave them to fish it out
  • [13:35] Zha Ewry: And you can't dependo n that, when users can hack them
  • [13:36] Saijanai: Kuhn: still wondering. Are we going with a URL for region domain? or should we use an agent domain as indicator of the "home" of an avatar?
  • [13:36] Zero Linden: UUIDs are unique if you trust all players
  • [13:36] Zero Linden: they are not if someone isn't playing nice
  • [13:36] Morgaine Dinova: So every object is going to have a hidden internal/local ID as well, to get over the case of collision or forging?
  • [13:36] Whump Linden: or if someone's doing it wrong
  • [13:36] Xugu Madison: Zero, or someone makes a screwup like they did with the Debian SSL key generator....
  • [13:36] Goldie Katsu: Trusting people to play nice is not the best security model.
  • [13:37] Zha Ewry: Less of an issue with objects
  • [13:37] Zha Ewry: much more with identity
  • [13:37] Zha Ewry: tho
  • [13:37] Zha Ewry: in fact
  • [13:37] Zha Ewry: long term?
  • [13:37] Zha Ewry: Yeah, everythign is a URL, in the best world
  • [13:37] Zero Linden: so we have conflicting needs here: 1) Just ensure for the current session - all the protocol that currently includes just an avatar's UUID - works in light of possibly different avatars with the same external UUID
  • [13:37] Saijanai: Kuhn: well, can we trust each agent domain to play nice? Use the Agent DOmain ID + agent ID ats the arbitratio
  • [13:37] Dahlia Trimble: gave you first few minutes of Zero.
  • [13:38] Morgaine Dinova: I don't think it's less of an issue at all. If UUIDs can't be trusted to be unique for av identity, then they can't be trusted to be unique for anything, in an interop world.
  • [13:38] Zero Linden: 2) Long term, how do we identify an agent reliably so your viewer can answer questions like -- is that the "mike meyers" I went to that party sim with?
  • [13:38] Xugu Madison: For actually saying "I am <person>", as opposed to "You can identify me as <UUID>", I think the answer has to be public/private key and signing
  • [13:38] Xugu Madison: So you get their public key first time you meet them, and your client then knows they're the same person next time you meet them
  • [13:39] Teravus Ousley: well, Morgaine, essentially the UUIDs are generated uniquely.. but afterwards the region domain owner can dig into their database and make it overlap
  • [13:39] Goldie Katsu: and in fact I have done that to make it so I can develop on one open sim and import into another.
  • [13:39] Saijanai: Kuhn: so, again, do Agent IDs come from the region or the AD?
  • [13:39] Xugu Madison: Actually, why are we importing UUIDs at all? Perhaps a blanket "Here, use this UUID while you're here" would be better?
  • [13:39] Teravus Ousley: Sajanai: the Agent domain tells the client which UUID to use
  • [13:39] Morgaine Dinova: Tera: and that's true for all objects. So I guess we *ARE* going to have to tag every object with hidden ident.
  • [13:40] Whump Linden: Xugu, what about scripts that depend on identifying if the actor is an owner?
  • [13:40] Xugu Madison: Whump, argh, good point
  • [13:40] Teravus Ousley: Sajaianai, but the region domain must be responsible for resolving the UUID conflict if it does occur.
  • [13:40] Saijanai: Kuhn: so, seems that the AD should be responsible for gnerate the Agent's UUID and if there is a collision resolve it by tacking on the AD ID/URL/UUID/whatever
  • [13:41] Goldie Katsu: That would mean a user would need a UUID on the primary agent domain for that region
  • [13:41] Morgaine Dinova: The trouble is, tagging objects with hidden ident and expecting it to work safely on object migration between worlds is identical to the problem of Fallacy of DRM. It's not actually a workable solution.
  • [13:41] Saijanai: Kuhn: no, for the agen't s OWN region
  • [13:41] Saijanai: Kuhn: own AD
  • [13:41] Teravus Ousley: We're not actually on objects yet.. we're talking about agents.. teleporting.. and intentional munging
  • [13:42] Zero Linden: So- the urk, legacy, that the owner ID in an object is just a UUID is - perhaps overcomable....
  • [13:42] Saijanai: Kuhn: AD:aditi.seconlife.com/AgentUUID
  • [13:42] Saijanai: Kuhn: should be unique
  • [13:42] Morgaine Dinova: Agents are not a special case though. If the problem exists for agent ident, it exists for all objects that migrate between worlds.
  • [13:42] Teravus Ousley: That's not the topic Morgaine :D
  • [13:42] Zero Linden: Now - we *could* have a (someone hold Zha down) central agency that hands out UUIDs for Avatars
  • [13:42] Saijanai: Kuhn: AssetServer:server.secondlife.com/AssetUUID
  • [13:42] Zha Ewry: moans and rolls her eyes
  • [13:43] Dahlia Trimble: lol
  • [13:43] Morgaine Dinova: Tera: they're one and the same topic
  • [13:43] Xugu Madison: I agree with Morgaine, actually, by considering these seperately we're just going to duplicate effort
  • [13:43] Goldie Katsu: administers absinthe
  • [13:43] Zero Linden: and that agency *could* be queiried with any incoming (into the region domain) avatar and check that that UUID is currently managed by the agent domain proffering it
  • [13:43] Zero Linden: So - put that on hold
  • [13:44] Zha Ewry: I agree, in theory
  • [13:44] Zero Linden: Morgaine it doesn't exsit for objects really- because it is reasonable to break the notion that an object can have long term global identy even if it moves from one region domain to another
  • [13:45] Zero Linden: (not to mention that it can't in any sense unless the region domains are adjacent and the object is moving....)
  • [13:45] Xugu Madison: Zero, problematic for scripts that refer to textures by UUID, for a start...
  • [13:45] Zha Ewry: In princple, the assdet story is going to be URLs to the asset store, and the rezzzed objects
  • [13:45] Zero Linden: (another reason that I don't want region domains to touch)
  • [13:45] Zha Ewry: get URLs too
  • [13:45] Zha Ewry: the UUID, is really, not a way to address a object, in the large
  • [13:45] Zero Linden: Xugu - that use case is problematic for many many reasons - Xugu --- BUT to be clear, those are assets, not objects
  • [13:45] Morgaine Dinova: Zero: so you claim that a unit of virtual currency is never going to have a global identity? You may be right, but it's going to make economists jump off bridges.
  • [13:45] Zha Ewry: fine for local uniqueness, but not global addressing
  • [13:46] Xugu Madison: Okay... if we're solving assets by URLs, can we solve people by URLs? I might https://archipelago.cs.st-andrews.ac.uk/user/Xugu%20Madison/ for example?
  • [13:46] Zero Linden: Morgaine - let's not hit that rat hole quite this time --- but clearly, at present units of virtual currency aren't objects
  • [13:46] Zero Linden: (in the SL sense of object)
  • [13:46] Saijanai: Kuhn: assume no AD allows duplicate names?
  • [13:46] Teravus Ousley: hehe
  • [13:47] Zero Linden: And - last I looked - my pocket change doesn't have serial numbers on 'em
  • [13:47] Morgaine Dinova: But your dollar bills do :-)
  • [13:47] Zha Ewry: I was about to say that, tho.. nobody looks at them unless they suspect fruad
  • [13:47] Zero Linden: not quite sure why they do ... they aren't tracked ( [3] not withstanding)
  • [13:48] Morgaine Dinova: The reason why coins don't have serial numbers is simply because currently you can't print coins.
  • [13:48] Zha Ewry: Allows blatent fraud detetcion
  • [13:48] Goldie Katsu: that's because it isn't convenient to scan serial number.
  • [13:48] Teravus Ousley: I would add some things about caps.. and check numbers and which linden's office hours.. but it's not the topic
  • [13:48] Zha Ewry: nods
  • [13:48] Zha Ewry: So, wihthout and authoirty, yes, UUIDs have holes
  • [13:48] Zha Ewry: In paritcular, when used as the basis for trusting things
  • [13:48] Zero Linden: and lo - economists aren't jumping off bridges.... at least not for the lack of large scale currency serial number checking
  • [13:49] Zha Ewry: No, more for the sudden realization they are way to clever for thier own good
  • [13:49] Morgaine Dinova: Cool. I'm looking forward to it, better get my L$ printing machine ready :P
  • [13:49] Whump Linden: so in the short term, is there anything we want to try w.r.t. uniqueness, given that we're implementing draft 3 at the moment and have a bit of plasticity?
  • [13:49] Zero Linden: So - it is tempting, and surely easy, to simply combine the canonical domain name of the agent domain along with whatever the agent domain wants to use to uniquely identify it's agents into a URL
  • [13:49] Zero Linden: and say THAT is the long term unique ID for an avatar
  • [13:50] Zha Ewry: That locks you down to a domain
  • [13:50] Zero Linden: it doesn't play well with current LSL scripting model -- though I imagine it could be shoe horned in...
  • [13:50] Teravus Ousley: haha, maybe pass it in the referer header?
  • [13:50] Teravus Ousley: (notice the intentionalspelling error)
  • [13:50] Zero Linden: And it would require assignment of a UUID on TP since the current UDP protocol is all interms of just UUID (another shoehorn)
  • [13:50] Dahlia Trimble: LSL is already shoehorned in so many places...
  • [13:50] Zero Linden: BUT ... what Zha said
  • [13:50] Xugu Madison: I tend to feel the LSL scripting model could do with a "few" changes, anyway
  • [13:51] Zero Linden: it locks the user to a domain for ever
  • [13:51] Teravus Ousley: you'd have to initate a zone transfer? :D
  • [13:51] Saijanai: Kuhn: howabout a birth "name"
  • [13:51] Zha Ewry: Well, it's your assets whic get trapped
  • [13:52] Zero Linden: (only "zone transfer" doesn't transfer control of zones....)
  • [13:52] Zero Linden: (at least not the DNS opcode)
  • [13:52] Zha Ewry: I mean, igonoring the problem of
  • [13:52] Teravus Ousley: yes.. I suppose a registrar transfer was more appropriate of an analogy
  • [13:52] Zero Linden: right
  • [13:52] Zha Ewry: "zha.ewry@lindnelabs.com an zha.ewry@osgrid.com not being necesarily the same person
  • [13:52] Xugu Madison: It's not like changing e-mail address is easy, either. Mostly, make sure people know what they're getting in for when they attach to a domain
  • [13:52] Zero Linden: BUT then - who is keeping that mapping of identity to agent domain
  • [13:52] Zero Linden:  ?
  • [13:52] Saijanai: Kuhn: a birth certificate that stays the same regardless of which AD you end up using
  • [13:52] Zero Linden: just like WHO keeps the mapping of domain name to registrar?
  • [13:53] Zero Linden: wait.... sounds like....
  • [13:53] Zero Linden: ...could it be.....
  • [13:53] Zero Linden: ....a central agency that hands out UUIDs for Avatars
  • [13:53] Xugu Madison: Nooooooooo...
  • [13:53] Neuro Linden: there is an analogy here; buying a new cellphone on a different network from your existing one, and porting your number to the new network - you'd still appear to have a vodafone or cingular number, but you're on a different network
  • [13:54] Zero Linden: The CIA: The Central Identity Agency
  • [13:54] Goldie Katsu: Looks for the number for IANA
  • [13:54] Morgaine Dinova: chuckles
  • [13:54] Zero Linden: wait, that acronym might have some bad connotations....
  • [13:54] Teravus Ousley: hehe
  • [13:54] Goldie Katsu: Confidentiality Integrity and Availability?
  • [13:54] Whump Linden: opens a JIRA, "Don't Be Evil."
  • [13:54] Zero Linden: Right - telephone number portability
  • [13:54] Xugu Madison: opens a JIRA "Be evil"
  • [13:54] Neuro Linden: a central agency could still have oversight, think the FCC or Ofcom
  • [13:54] Zero Linden: I think is an important lesson
  • [13:55] Neuro Linden: not saying they're *good* oversights :)
  • [13:55] Zero Linden: One of the few things the public has ever successfully pushd down the telcom's throat!
  • [13:55] Zero Linden: glances as how well breaking up the monopoly has gone....
  • [13:56] Whump Linden: and there is, in the US, because of number portablity, a central mobile number registry, but I forget the name of that org.
  • [13:56] Morgaine Dinova: A system of delegations like DNS would seem to be a good approach. Presumably nobody wants centralization, other than the AD services themselves who are always going to be control freaks, that's a given.
  • [13:56] Goldie Katsu: counts the number of phone providers
  • [13:56] Goldie Katsu: LURG?
  • [13:56] Zero Linden: whereas in GSM - people get phsyical crypto tokens that contain their unique number....
  • [13:56] Zero Linden: ...but I suppose there is still a central agency giving them out
  • [13:57] Goldie Katsu: Yes.
  • [13:57] Zero Linden: OH - wait perhaps that is a way out
  • [13:57] Dahlia Trimble: and providers lock the phones so only their GSM cards work
  • [13:57] Zero Linden: have a central agency that issues UUID/publickey/privatekey sets
  • [13:57] Neuro Linden: Dahlia: that's a commercial issue however
  • [13:57] Zero Linden: not in Europe they don't lock 'em....
  • [13:58] Goldie Katsu: and you can unlock a phone
  • [13:58] Neuro Linden: Zero: territory dependent
  • [13:58] Zero Linden: But users are notorious for not handling small digital keys well
  • [13:58] Neuro Linden: handset locking is still common in europe
  • [13:58] Teravus Ousley: that would also work with the SSL + client PEM + trusted CA issues.
  • [13:58] Zero Linden: sigh - see - and everyone's always holding Europe up as the land of cellphone-nirvana
  • [13:58] Neuro Linden: Belgium, maybe :)
  • [13:59] Xugu Madison: It's all fun and games until you want an unlimited data plan
  • [13:59] Goldie Katsu: But yes, transfers between providers cells is a tricky business highly based on trust.
  • [13:59] Zero Linden: hopes Infinity isn't here to hear me whisper "client certs"
  • [13:59] Neuro Linden: unlocked handsets are usually always available from the manufacturer, for the unsubsidised cost,but i'm wandering off topic :)
  • [13:59] Teravus Ousley: .. though.. the certs would be at the agent domain and .. region domain.. .
  • [13:59] Goldie Katsu: nods at Neuro and tries not to continue the tangent.
  • [13:59] Xugu Madison: Okay, so solve it by using 2048 bit RS Akeys as ident, so the private key is never handed out?
  • [14:00] Zero Linden: well, there seems to be some desire to give users ultimate control and ownership of their identity
  • [14:00] Zero Linden: sighs that UUIDs aren't enough bits to be a public key....
  • [14:00] Teravus Ousley: Looks like we'll not be able to get to #3.. Teleport to location.. so can we make it a thursday item?
  • [14:01] Goldie Katsu: as long as no one runs a program that takes their key and sends it elsewhere
  • [14:01] Morgaine Dinova: In UK most mobile providers will sell you an unlocked phone for an extra charge, and many large cellphone retail sites sell *only* unlocked phones as a policy. Plus, unlocking is a substantial business, not black market, and a mobile operator cannot refuse their SIM being used in an unlocked phone.
  • [14:01] Whump Linden: I would like to make it to that discussion, but I've got a doctor's appointment thursday that conflicts.
  • [14:01] Zero Linden: Teravus - sure - remind me when I call for agenda that it was tabled from today and I'll put it on top
  • [14:02] Zero Linden: okay
  • [14:02] Zero Linden: I've got a packed afternoon
  • [14:02] Saijanai: Kuhn: UUID+UUID?
  • [14:02] Zha Ewry: And then add Truyst between components as next
  • [14:02] Teravus Ousley: well, next tuesday then..
  • [14:02] Zha Ewry: Thursday
  • [14:02] Zero Linden: but this conversation has germ of a direction out of the agent id morass.... I'll be spending some time in front of a whiteboard this week....
  • [14:02] Zero Linden: later
  • [14:02] Teravus Ousley: (next tuesday for whump)
  • [14:02] Zha Ewry: ahh
  • [14:02] Zha Ewry: yes
  • [14:02] Whump Linden: Thanks.
  • [14:02] Zero Linden: thanks all for coming
  • [14:02] Neuro Linden: as an aside, here's how mobile number portability works in the UK: [4]
  • [14:03] Morgaine Dinova: Thanks all
  • [14:03] Neuro Linden: could be some interesting useful tidbits inside :)
  • [14:03] Xugu Madison: Thanks eveyone for hosting/oming, hope I didn't drive you all crazy :)
  • [14:03] Dahlia Trimble: thanks all, bye :)