XMPP Summit - 2013-01-31

https://cisco.webex.com/cisco/e.php?AT=WMI&EventID=215959417&PW=ae8ea25b403f203f&RT=MiMxNDc%3D

Neehaw

wooo

Ralph is a hater.

he is not well-formed...

must be that crazy Twisted stuff.

Ralph is really testing Swift's ability to summarize presence changes.

:)

:)

it's too bad, but I can't hear anyone on the other end of the room. It'll work better when we break out into groups, I suppose.

fritzy; It's good, though :D

Kev: oh yeah

I never know what to say for these introductions

"Bear". Your name's "Bear".

:P

yup

Happy to help.

fritzy: it was hard to hear some of those people IRL

There. He remembered, phew.

the JSON stuff isn't about changing XMPP.

yea, that is what we need to keep reminding folks

It's about making a bridge that can run at any layer for the increasing percentage of web developers

"as is traditional..." and then the audio cut off

Peter's saying there's lots of stuff we do.

If you want to attend the dinner tonight, and haven't filled in the menu yet, do so now

https://docs.google.com/spreadsheet/viewform?formkey=dExlcTBGN2lyYzlJb1h3OEI4cXBicGc6MQ#gid=0

You know all this.

ah, ok. Strange that the audio suddenly stopped working.

Is it back?

no

he's summarizing the areas people have mentioned to start getting working groups set up

this'll be more useful in a smaller group setting anyway

I don't think I have any power to d osomething here.

it's ok for now

I'll just participate in the smaller groups as I can

OK.

if something new is said I will try and repeat it hear

MEP, WebRTC, WebSockets and Bosh

we know now that long polling is not the issue

Not the solution, rather.

jim is redialing now

well, now that we have something better

err joe

Geeze, Joe is a legend, and you get his name wrong?!

;)

new keyboard

I'll try too

bear: Keys all in different places?

now he is talking about internationalization and mobile support

kev: no - my thumbs are in new places

Ah. I hate it when that happens.

dave!

Mike!

there is a webex setup

ok, audio should be back?

Ah - where away webex?

ok, I have audio now

dwd: https://cisco.webex.com/cisco/e.php?AT=WMI&EventID=215959417&PW=ae8ea25b403f203f&RT=MiMxNDc%3D

I'm good to stay up all night.

So I heard.

current thoughts JSON object model

wire protocol isn't necessary, but may be done in certain situations

fritzy: let us know if you'd like to channel anything to the room for you

http://wiki.xmpp.org/web/Summit_13 | https://cisco.webex.com/cisco/e.php?AT=WMI&EventID=215959417&PW=ae8ea25b403f203f&RT=MiMxNDc%3D

yeah, let me know when I have a chance to summarize my thoughts

fritzy: will do

fritzy: our audio is not so great here so we might need to repeat some of what you say here (or crank it up to 11!)

erreven!

It's important to clarify that this is a subset of XMPP. It's not extensible, although we might have a XEP for passing generic JSON blobs.

This webex thing is fun. All the power of Animated GIF.

Oh, and now buzzing instead of audio.

Buzzzzzzzzzz

oh, fixed

Unless you've all started monotonically humming?

sorry, that was peter.

Ah, for me as well.

sorry, was playing with the audio settings here

Dave: are you not in the room then?

I'm in *a* room...

hold on!!!

I hung up on you

fritzy: We hung up on you (apparently)

oops

he he he

please hold :)

what I was saying is that as far as what developers wants varies greatly

the commonality is that they won't touch XML

because their XML tools have been so bad for so long

and when they think about extensibility, they're thinking about sending their own blobs as payload

but that does not sound extensible

;-)

we still need to get the audio working again

NO NOT REST

No REST for the wicked.

Not REST... we're not talking routing or verb translation.

sorry - rest is just my comfort area for web stuff

There is some code. stanza.io

you're back

on audio

I can't here any of this (aside from PSA).

He's the only person near the mic.

Right.

Federation, security, etc.

"Some people want presence+routing. Other people want pubsub."

Steffen was just saying that we can't solve all problems, but we can work out a common lib.

presence, routing, rosters, identity.

fritzy: right

common requirements, for an API>

basically: what can we provide to be better than socket.io

fritzy: exactly

and then pubsub

fritzy: pubsub in 1.1 or whatever

fritzy: or a more native pubsubby thing

yeah

Right... strophe expects you to write and parse XML, and no other lib forces you to do that

fritzy: yes

Strophe is mostly just a BOSH connection manager.

It's simply not enough

fritzy: yes

that's right

and it's not even just about XML... we're expecting application developers to write the wire protocol.

Right, they want to take some simple API, and throw a javascript object at some endpoint, and get one back.

exactly

now that's not to discount the people that want to do more, so I disagree with some of the things you were saying (that it should never be more than that)

Yes and no. For things like MUC, I'm not sure if doing anything different on the wire is the right direction - I think a neat layer over STrophe is possibly the better chocie.

(Sorry, typing shot this morning).

sure sure... an I agree. But we can kill two birds with one stone... we can make a JSON SDK that can /potentially/ be translated on the other side of the wire.

s/JSON/Javascript object and native feel/ and you're on.

I still feel strange that we are talking about SDKs when we are doing protocols.. :-)

Because the SDK is what's visible, and that's what gains mindshare.

Dave: I know..

With most of our protocol design, we talk about end-user (or end-entity) actions, then see how to translate them onto things on the wire. Here we're a layer down, is all.

Well, that's why people love JSON... because it can be a Javascript object OR a serialized thing

So apparently Buddycloud has its annual company outing

so... is there anything going on in the room right now? cause we have no audio

fritzy: We're ascertaining interest in the topics.

no talking about the different topics

I'll kill my video so you don't have to stare at me picking my nose then.

I'll point my video at the dog.

lol

your dog is licking itself, I think

He's having a scratch.

we'll be back in 15mins

k, what are the breakout groups?

we haven't decided yet

Oh, the dog's gone camera shy.

i'm going to Google+ them

they are taking a bio brak

oh, I thought that was what was being discussed. :)

the topics are on the G+ event

i'm trying some other A/V options while we're taking a break.

Florian yeah? I don't see an event...

\o/

w00t

How've you been, Zash?

I'm making coffee and Dave is making tea.

fritzy: sent you an invite to the event

anyone else not part of the XMPP Summit e ent?

I'm in G+ Party Mode streaming some pics there

topics are up

https://plus.google.com/events/c7apt48oi63qoi07a6a5psaf8fc?authkey=CProyqyywtGFHw

For file transfer, look at XEPs: 95, 96, 65

for a good time, call Joe

fritzy: Fine, thanks. I arrive. Except now we're out of coffee. I may have had something to do with that...

can you hear him?

Kev: Tobias did implement -PLUS, but it has not been merged yet

bear: yes

thanks guy

s

http://go.estos.de/chat/#0hgo7on5

lance - what is your jid? I just realized I don't have you in my roster

WebRTC and MUC: http://candy-chat.github.com/candy-webrtc/

Alexey tried to make DIGEST-MD5 use saslprep, but as I recall is was a rathole.

dave: that's my recollection. the whole idea of having a separate *prep for SASL vs. your application protocol is a little wonky anyway.

hildjj, Well, given that SASL authentication identifiers are already technically unrelated to the authorization identifiers from the protocol, maybe it makes some weird kind of sense.

Not that I can really hear much of what's said, but Kurt Zeilenga's take here is that it makes sense to have multiple jids, one in ASCII and one not, and either have some mechanism to find out the real non-ASCII jid from the ASCII handle, or else have the server actually remember which jid alias to use for which contact.

Did you just say 'jid alias'?

Zash, Yes, but actually in the sense I used it I mean jid equivalent.

Dave Cridland: Yes, but that's to solve a different problem.

Kev, Ah, OK.

Kurt's argument for having an ascii and a non-ascii is so you can put easy things on your business card or whatever.

Rather than suggesting that Japanese folks need to have an ASCII JID.

Kev, Right.

Kev, But ISTR his general goal is remote canonicalization.

with something like punycode?

Where is the microphone? Because I now can't here Kev, even. Is it shielded by the laptop lids?

I'm just not shouting any more. I was making an effort TO PROJECT earlier.

up front

Kev, You is becomin' an hack-toor?

Can you hear Kev now?

Very much so.

If he projects much more we can drop the webex, I think.

he's presenting now

Of course, I can't see his diagram.

better?

Yes. Though for a brief moment I could only see his crotch.

hah

TMI

What darkrain said

here's a muc, there's a muc. everyone muc muc

you beat me to that joke :)

Great minds and all that.

These two mucs count as one muc.

Did Kev say MUCeption?

Everything needs more MAM!

You can turn me round again now.

Zash: +1

Ta.

End <- encryption -> End

like that?

We have a discussion about e2e encryption every time, so should have one this time if only for tradition's sake.

can someone just tell us how to do it properly this time?

Somewhat related to Federated MUC is the Zookeeper project ZAB: http://research.yahoo.com/files/ladis08.pdf

Lance, The encryption bit is easy, it's the authentication and key exchange bit that's so damn hard.

did we lose audio?

oh, there it is

fritzy, They lost speech.

I have a lot of opinions on xmpp as middleware

ok, I just have one big one.

Don't do it unless you're federating data.

I think it also depends on where your middle is.

xactly

XMPP does to the auth stuff pretty well.

does do.

right, but middleware is often network secured rather than identity authed

fritzy: no thats not always true..

often, as I said

:-)

Right, purely internal middleware is not interesting, but if your middleware is talking over the internet, say, that changes things whether federation is in play or not.

right

don't bother unless it's going over the public net

I personally suspect that middleware is talking over mobile links and direct-to-browser a lot more than it used to.

sure sure... clients are further out

dave: yes, it is

social network: might wait for Simon tomorrow?

He's here

fritzy: He's here.

oh

fritzy, I think he's that collection of eight pixels towards the end on the left.

this cisco tech is really amazing

It's like being in the room.

In a parallel universe where you see in 8-bit games console graphics.

yeah well, most of it is filled in by my imagination and remembering actually being in that room

haha

Florian, You can't laugh, you weren't born when we had graphics this bad.

it's like that dream where you can't see anyone's faces

this staying awake all night thing was easier when I was younger

I think if we solve the web-integration problems, that the social network stuff will come

because the social network people will come

fritzy, I think that's certainly a lot of it, yes.

i'd be happy to shut the camera off if it's not helpful.

hildjj: what would we complain about then?! ;)

there's no camera that could shoot this room.

it's helpful. Thanks Joe. Sorry for complaining

right. the problem right now is that it is too simple and easy to build a silo system, compared to integrating xmpp

the lighting also sucks, which doesn't help.

it's like WebRTC, but with more angle brackets, and a bunch of namespace stuff you won't understand.

But it's OK, we can show you how to copy/paste.

right, we have a strong sense of identity

I repeat... if we solve the web integration problem, they'll come.

There's an inherent "that XML stuff is scary; I've seen SOAP" attitude, perhaps

fritzy, Universal identity and addressability, no less.

darkrain: yes. but i'm tired of fighting that battle.

partially because i agree with them. XML blows.

it's a battle not worth fighting anymore.

time for an attitude change

I agree; just need to find a way to side-step it.

right. i've been at least as much of a problem as anyone else for maintaining the status quo, and i'm trying to not be anymore.

:)

Cridland: "XMPP: Universal identity and addressability" sounds great.

simon, i usually say "identity-based routing"

id, presence and routing.. thats how I use it as middleware..

What about scaling, how do you tackle bottlenecks in a federated system?

sekistner: it's always the other guys problem. :)

SimonTennant, Yeah, it's a bit sound-bite-y, but it's the basic thing - every entity in an XMPP network, from the user (or their account in abstract), and each connected client or server, are all given an addressable name.

sekistner: implementation problem... and implementations have solved it.

sekistner, I'm not sure I understand - when a system is highly federated, it tends to scale better (because other people take on more burden).

webrtc people.... GET OUT

get a room

ok, i'm going to drop from webex. peter can crank the a/v back up.

uhh.. ok

Not in the web usually. If twitter was federated a retweet from Justin bieber kills a small server.

That's why "web-scale" is a thing ;)

ugh...

can you guys hear me?

nope

no?

so sad

fritzy: your screaming?

we're wailing

haha... thanks stpeter

Zash: https://www.google.com/search?q=mongodb+is+webscale seems relevant

video?

stpeter: doesn't matter.. but if you could hear me, that'd be nice.

chaos is good networking

websocket/bosh is a solved problem

fritzy: right

A Chaosnet reference?

Yeah you make fun of web developers and wonder why they ignore xmpp.

:P

I'll be back in 20 min

Whitepaper chat: http://piratepad.net/CROClrYlXo

http://tools.ietf.org/html/draft-daboo-aggregated-service-discovery

no :(

Dave Cridland:

So I can hear Peter really well, and the video's pretty good, but I can only hear Ralph if he faces the laptop and talks pretty clear.

Argh! Giant hand!

HAha

IT'S ALIVE

Dave: Better audio now?

Yes, that's good.

bakc

TINS: http://xmpp.org/extensions/xep-0111.html

fritzy, We're talking pubsub.

fritzy, Well, they are. Strangely, the video's gone back to 8-bit mode.

ok, thanks

This is a shame, because I can no longer read the whiteboard.

Dave Cridland: https://www.youtube.com/watch?v=4qsWFFuYZYI

Oh. Suddenly, I can see PSA's desktop.

BACON!

Yeah, I heard Bacon...

what do you think aboutmoving item retrieval to the extensions spec?

But I wasn't really paying attention.

OK, I'm all in favour of moving things out of XEP-0060.

so we're slimming pubsub out?

I'm not in favour of moving them into another kitchen sink spec.

we could do a "non-recording" version of pubsub

and then have a storage/retrieval extension

Is there a persistence feature?

normally, yes... the idea might be to move that to its own extension

I've never been sure what "persistence" means in terms of pubsub, actually.

items being retrievable

beyond the initial notify message

fritzy, No, I don't think so. I think that's controlled by max_items, not by persistence per se.

SO not about node lifetime at all?

sure.. but they're talking about max_items, and persistence and retrieval being on the side

yeah

RIght, I could go along with that.

Right, http://jabber.org/protocol/pubsub#persistent-items was the disco feature

FWIW, one thing I've seen from being engaged in sales calls about pubsub is that every single customer has a different set of requirements for a pubsub service, and there's too many possible variations.

Everyone not in the A/V breakout, please ignore this:

<message to='juliet@example.com'> <sox xmlns='urn:xmpp:sip'> INVITE sip:juliet@example.com SIP/2.0 Via: SIP/2.0/UDP soxcat.example.com;branch=z9hG4bKnashds8 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: &lt;sip:alice@pc33.atlanta.com&gt; Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 pc33.atlanta.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 </sox> </message>

hildjj, Tunnelling SIP inside XMPP verbatim?

yes.

SIP over XMPP: SoX

dave: you're not supposed to listen to this ;-)

fippo, No, because it makes my brain hurt. I can (readily) go along with SDP tunelling; but throwing out Jingle entirely in favour of SIP doesn't strike me as a step forward.

Dave Cridland: SDP tunneling makes some sense for various reasons, including CUSAX clients (which we'll discuss tomorrow when Emil is here)

Addressing for federated service * http://tools.ietf.org/html/rfc3958 * http://tools.ietf.org/html/draft-ietf-precis-nickname-05 * http://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-02

Kev: http://storify.com/kleinmatic/brewing-fresh-coffee-on-an-airplane-as-one-does

kev: can you create an email alias for howto@xmpp.org and have that go to me, winifred and florian ?

Hrmph.

I've made it go to just you.

will do :)

*please*

Email for florian and winifred, please.

*Winfried

florian@florianjensen.com

winfried@tilanus.com

yea, I know - as soon as I pressed enter I reliazed I spelled it wrong

that's the american english way I guess

should have done a last message correction

Swift.im will live for another day :)

hehe - yes, now that i'm running a real client

Kev: I'm screwing things up, ignore my changes to aliases

Peter - you're editing a file I'm alre...

Right.

looks good Ralph, Peter

+1 on the new organization

fritzy: thanks

the spec 1 group maps very cleanly to things like redis pubsub and socket.io

oh yeah, defintely just spreading it out

oh... XEP 60.1, 60.2, 60.3

ha

:D

XEP 0060a

haha

0060bis

b,c,d,...

oh, can we reserve a block?

I mean, what if we need more xep 60?

;)

xep L60

we could start naming them like cellphones

'T'

XEP-0060/255.255.255.0

Hahaha

XEP:60::1

And add several others.

Kev: nice :)

sorry peter, did not realize he had started

bear: no worries :)

http://howto.xmpp.org is live.

thanks kev

yay

Enn Pee.

wuhu! :-)

LOL

just watch sales skyrocket now :D

Subtle ad, there.

Kev: You forgot the HTML5 doctype!

kev: I should write a book myself!

winfried: Sure, but ours should stay first in the list.

https://datatracker.ietf.org/doc/draft-daboo-aggregated-service-discovery/

Abstract This specification describes how clients can discover multiple services to configure themselves with a minimum of user-provided information, as short as possible sequence of queries and with a minimum of overhead for administrators of the services.

stpeter: It's an RFC

https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/

Zash: what is an RFC?

I thougt it was

Zash: WebFinger is not an RFC yet

it's in Working Group Last Call right now

or did I get that mixed up with that other similar thing

http://tools.ietf.org/html/draft-jones-simple-web-discovery-02

The top half of this door really is interesting.

I.... am.... still... awake....

Kev: +1

Insitutional carpet. Nice.

zombie fritzy

fritzy: given you don't get any sleep now, couldn't you just as well come over?

naw, it was good that I stayed home

But we miiiiiss youuuuu.

aren't you mostly useless now there?

Kev: yes (http://blog.silktide.com/2013/01/the-stupid-cookie-law-is-dead-at-last/)

Combined Community Codec Pack <http://en.wikipedia.org/wiki/Combined_Community_Codec_Pack>

:D

http://tools.ietf.org/html/draft-resnick-on-consensus-00 feels relevant

oh I do!

kev - be nice to the 4AM brain of peter

that was "tanstaafl" or "there ain't no such thing as a free lunch"

An acronym from The Moon Is A Harsh Mistress, I think. Though it could be Stranger In A Strange Land, now I think of it.

Moon is a Harsh Mistress

Shouldn't Peter refer to "Bad Actors" as "Waiters"?

florob: mimiking!

I was in that conversation

prosody implements everything

:)

Implement all the things!

ipv6... every client is a server!

fritzy@[5222::0123:4567:89ab:cdef]

:D

Yes! who needs DNS?

Catchy EUI64s.

it works

Zash, I think I might just have missed some conversation being half asleep

Florob: Lots of peter@jabber.org

clap clap

Right, some testing/experience how well confusable mappings work against that would be interesting

Zash, Florob: How much of that is due to 6122 (and 3920(?)) discussing cherokee versions of 'stepeter'?

darkrain: My thougt also

time for me to get the kids ready for school

see you guys tomorrow!

GN.

http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00

http://developer.cisco.com/web/jabber-developer/get-started ?

https://tools.ietf.org/html/draft-miller-xmpp-e2e-03

that's for end-to-end

I like DNA / DANE

The DNA framework: http://tools.ietf.org/html/draft-saintandre-xmpp-dna-00

DNSSEC/DANE: http://tools.ietf.org/html/draft-miller-xmpp-dnssec-prooftype-03

http://tools.ietf.org/html/draft-miller-xmpp-posh-prooftype-01

This bit about if the SRV is DNSSEC-secured, allow the target name in the certificate. I have a patch for this for prosody.

cool!