XSF Discussion - 2019-11-20

a question: https://fosstodon.org/web/statuses/103166428834063205 @sofia@chaos.social @xmpp hi there! i was wondering if XMPP has any standards or plans for self-verifying IDs? like if my public key (or it's hash) is a4244aa43ddd6e3ef9e64bb80f4ee952f68232aa008d3da9c78e3b627e5675c8 then my id could be a4244aa43ddd6e3ef9e64bb80f4ee952f68232aa008d3da9c78e3b627e5675c8@jabber.ccc.de and so everyone who knows my id automatically has a verified, secure channel to me.. sofia @sofia@chaos.social oh, the same question goes to @matrix , too! it may even be more relevant to #matrix because i think they have a single default e2e encryption scheme, unlike XMPP. #selfVerifyingID

Like adding your omemo ID to your jid in conversations?

xmpp:info@mdosch.de?omemo-sid-709870363=951898c88f683d55e7fe74dc9b8980489162d251b140bd9e5ccd8d28f7f7dc70

If you add me with this link in conversations you'll automatically have my omemo key verified. Don't know if it's included in the omemo xep and other programs support this too.

Maybe Daniel can clarify.

!XSF_Martin: I think the underlying idea is to use your key-id as an identifier instead of the localpart of the JID

if followed consequently, the domain part will be merely a routing identifier, i.e. "I'm currently holding my temporary state at jabber.ccc.de, but tomorrow it might be fancyjabs.biz"

Where is this more unique/verified than your jid?

The Matrix folks are in the process of retrofitting this mechanism after they found out that having a server responsible for your identity is a "dumb" idea ;)

Oh, so that would need some sort of registry?

!XSF_Martin: no. it would need servers to verify your proof of key ownership

!XSF_Martin: but the resulting protocol would be a different subset of Zooko's triangle

<https://en.wikipedia.org/wiki/Zooko%27s_triangle>

As a self hoster my domain and my jid on my website is proof enough for me. 😂

nyco: does that help in answering?

nope, I don't understand this discussion, sorry... :) I suggest some of you (who have fediverse accounts) engage the conversations, or you suggest me a text answer that I will post as @xmpp

nyco: text suggestion: In the federated XMPP IM network, user identity is always enforced by the respective servers, allowing for human-readable identifiers, and there are no current plans to change this. You could create an overlay network, where user accounts would authenticate to a server by their keypair, and the username part would be a hash or fingerprint resulting from this. To be secure, that approach would require that a client signs every piece of information that is stored on the server or transmitted to other systems, and each other system will have to verify that signature. The domain part of your ID would become merely a "drop box" for the data sent to you, as you could re-register with your key pair on any other domain, and XMPP would be just a routing layer for your overlay network with your currently-used server as a single point of failure. Eventually, you will realize that XMPP is not a perfect routing layer for such a protocol, and that there are better protocols for the requested traits of Zooko's triangle <https://en.wikipedia.org/wiki/Zooko%27s_triangle>

I hope this take isn't too cynical

at some point you end with the "dead drops" that vuvuzela.io uses

Vuvuzela: > Vuvuzela is a private chat application that hides metadata, including who you chat with and when you are chatting. Also Vuvuzela: > Create your Vuvuzela account [_] I am not a robot (reCAPTCHA)

Only reinforces me in my opinion not to trust things hosted on .IO domains

nyco, I think you touch on the answer there. Using hashes as addresses (which was first discussed for email, incidentally) has problems because you end up with a fixed (ie, non-agile) encryption mechanism. Moreover, what if a key is compromised? To have access to the key ends up implicitly granting access to the identity, so if your key is changed then so must your address. XMPP has tried overloading portions of the address with meanings other than routing; it really is a painful problem when those meanings diverge.

nyco, An alternative solution is a secure method for binding a key to an identity. X.509, for example, uses a trusted third party to verify this, PGP uses a web of trust instead for much the same result. Many E2EE solutions use an-person verification solution (QR codes, fingerprints, etc), or simply "leap of faith", where you prove consistency rather than identity.

nyco, FWIW, I don't think the question refers to Zooko's Triangle, since the question doesn't care about human readable names, but that notwithstanding, Ge0rG's answer is correct.

While the question does not refer to it, I still think that it's a valuable hint in understanding the problem space.

Even though I disagree with the Wikipedia list of things that have "solved" Zooko's

What's the most up-to-date specification that we have on message deletion?

or ephemeral messages?

There was some discussion on this a while back, but did that ever make it into a XEP?

Guus: You mean actual deletion/retraction or the whole routing 2.0 thing?

https://xmpp.org/extensions/xep-0424.html and https://xmpp.org/extensions/xep-0425.html are new

424 is what I'm after

thanks

“09:14:13 Ge0rG> Only reinforces me in my opinion not to trust things hosted on .IO domains”, yet you use poez.io!

origin git://git.poez.io/poezio (fetch) Damn it.

Ge0rG, re hash as localpart, there could be non-trivial infrastructure added (DHT etc.) to allow this, and then a different bind method etc.

The rest of the addressing would be the same

It's not done at the moment, but un the same way we now have a CA XEP we could have a DHT xep :P

pep.: you'd only lose one of the basic aspects of XMPP

how so

that servers are responsible for managing accounts on them

a completely different question: a friend of mine is looking to integrate with Google Firebase via XMPP, and I can't even understand how Google is making use of XMPP for that API from the official docs

are there any resources for people who *do* know how XMPP works?

https://fosdem.org/2020/news/2019-11-19-accepted-stands/

yay

Woo

> but who will be where will be announced closer to the event.

Ge0rG, servers could still be responsible for managing accounts on them. A user could choose where to have their account managed, and could also easily decide to move them around

Interesting to find out if we get more space this year!

(that's one possible answer to <moved/>)

People lose their keys. Massive pain to have a key be your identity.

Thaat's their issue, and it's always been

They currently lose their password it's the same story

a password can be changed

Has Summit 2020 dates been set?

if your identity is tied to your key ...

jonas’, the operator has the responsability to decide if they allow giving access to a potential attacker :)

I prefer to leave this responsability to the user themselves tbh

Zash, yep, before FOSDEM

it's been tweeted somewhere and on the wiki yeah ✏

ralphm, any idea why Matrix is not included in the realtime lounge again?

Why they can be separate from everyone else

Next year can we have XMPP splitted as well if so?

Marketing reasons I assume

Why can't we have marketing as well

pep. Probably history: the Realtime Lounge predates Matrix.

at the time, joining forces gave better chances of all related projects being accepted.

That doesn't really explain it to me. "Hey Matrix! We're going to put you in the realtime lounge", done.

That suggests that Fosdem organisation re-groups they applicants.

I already raised this "issue" a few months ago fwiw

The realtime lounge is being asked for by a group of related projects. Matrix did their own request.

Ge0rG, The Firebase XMPP interface is actually a legacy one, which is why the docs are sparse.

We could ask them to join us, or we could ask for our one spot

Guus, maybe we need to do the opposite then? Request a slot for XMPP itself

David Cridland: what's the official FCM API if you need upstream messages?

I thought it was HTTP/2 for the shinies - you need messages from device to backend, do you?

I already know from Android development that you need at least one full-time developer just to keep up with Google changing APIs

David Cridland: exactly

pep. yes we could do that. I'm not sure if that improves our chances of getting a spot though.

If we can apply to both, I guess is fine. Otherwise we would risk it and lose the spot entirely, is it?

Ge0rG, Send a normal push and then have the app callback with an XMPP session? :-)

Guus, well Matrix is getting their own.. I'm not sure why not

Also, didn't know there was Saturday-only and Sunday-only stands.

David Cridland: was that ironic?

because there's a status quo. Also, other projects in the realtime lounge put in quite some effort to get things organized.

pep. we can totally have XMPP marketing there, and we've done that since forever

Ge0rG, Not entirely. But I don't know that it's a terrible idea - I find the feedback from Push pretty poor at the best of times.

Doing it as the Realtime Lounge just gave us a better chance of being accepted, than each individual project (XMPP, Jitsi, other RTC projects) on their own

David Cridland: https://firebase.google.com/docs/cloud-messaging/android/upstream clearly says that you need FCM XMPP for that

Ge0rG, Oh, still? Well, that's good I suppose.

David Cridland: feedback from your developers doing Push regarding reliability / real-time?

ralphm, people see "Matrix" and they don't see "XMPP"

We're not playing on the same field

pep.: XMPP isn't a FOSS project

Zash: the dates were announced even by e-mail on several mailinglists on Aug 11, including summit@.

Ge0rG, You might be able to make some sense out of the Python asyncio FCM library, I know that uses XMPP.

pep. on the schedule you mean, yes, that is true. On the floor, they totally see XMPP.

Zash, that's another problem sure. XMPP unlike Matrix is not a standard, an implementation, a company, etc. all at the same time

Note that we get a lot of benefit from bundling forces. Saul does most of the organizing and often is manning the devroom too.

Our exposure on the floor is pretty good

David Cridland: let's move this into private chat. I'm currently looking at Smack as an FCM client library

(we could improve the look and feel, but there's definitely a XMPP presence - basically all of the lounge is XMPP)

Ge0rG, I think our exposure is pretty bad, but that's another topic

In the corner where nobody goes

Yeah, we've asked for more space in a different location

but that wouldn't change by going at it alone - if anything, we'd get less space. ✏

FWIW, +1 to different location - we're very much in the corner at the moment. But also quite happy as a group.

For years, XMPP effectively took all of the floor space that is ment to be shared with a few projects - so we're not doing bad there.

Yeah, the location thing has, again, be asked for explicitly. But that's out of our hands.

It's a pretty cozy corner FWIW

The corner isn't to bad, but it now has to many stands in it

ralphm, Oh, my wife says to ask you for green hoodies this year.

Who decides for the hoodies btw? Can anybody see the swag before it gets printed?

So, by doing our own application, we'd reduce the chance of being accepted, run the risk of getting less space on the floor, will have to do our own organizing (especially for the Dev room). Only to get 'XMPP' printed on the folders? For me, that's not enough added value.

pep. we desperately want people to provide content there!

last year, Dave and Ralph came up with designs

I didn't!

but please, suggest stuff

the bottle openers were yours!

And as noted, FOSDEM is more for FOSS projects, which XMPP isn't.

Oh, the text, in which I missed a better gag.

See, we need better content pep. - dwd has been failing us! 😃

The original (grey) hoodies were my design, though.

Classic

I think we should do pens and notebooks if we can, must be a "messaging" joke there.

Letter openers?

For extra fun at the airport

empty cans with strings.

Haha

we'll brand them "Matrix" >;-)

Nice.

✏

A new t-shirt design would be good, if we could think of one.

Can't be me then.

stream management.

That was Jonny.

fun things happen when a client reconnects using the same resource

Oh, interesting.

Guus, isn't that what is done nowadays? :x

(using the same resource)

Replacing the previous one instead of resuming it?

ah

There's a couple of things going wrong. Long story short: the new session is kicked after the TTL for the original session elapses.

But with various periodic tasks, and behavior different between clients, and a requirement of a previous session to have existed, made this hard to reproduce 🙂

Reference to the resource instead of the session itself?

pep., I shared my designs with several people involved with organising for the Summit / FOSDEM before they went to print

Zash yup

ralphm Do we still have orange ones? I ruined mine 😞

David Cridland, suggestion of 'Green Hoodies' noted.

Green like the logo?

ralphm, It'd be quite fun to have a rainbox of colours available.

Logo colors?

Guus: a couple, but maybe not all sizes. I'm not at home right now, but can check.

Photo shoot with people arranged in the shape of the logo, with proper colors?

David Cridland pretty expensive too, if you want to do them in all sizes.

ralphm thanks

David Cridland, the problem with many color options is that I would want to know upfront who wants which size/color.

FWIW, I have to admit I don't much like the sleeve print. Perhaps I'm too old and uncool for that.

Potentially anyone travelling from the UK with merchandise for sale at FOSDEM may be in an interesting situation next year

David Cridland, quite

MattJ, nah, https://twitter.com/julianpopov/status/1185664196178042880

MattJ, why? You'd leave before brexit, but come back after :-D

The XMPP logo we printed on the flyers for Capitole du Libre last weekend was much darker and less shiny than on a computer screen. :(

Would that make me an exporter from the EU??

Paper is hard.

Also, the better plan recently has been shipping it to my address, as we also have a van for the event.

ralphm: add some XMPP-branded sweets and you can spray "free candy inside" on the van door

LOL

Yeah, our region is market leader in that stuff. Should be easy.

Reminds me of the Breaking Bad session at RealtimeConf: https://vimeo.com/77799055

Oh, how I miss RealtimeConf

Indeed

hah that's a cool session

pep., did you have Prosody stickers btw?

I did

There's like 5 left

pep., 'cool' doesn't even begin to describe this. This was a conference with its own novel, graphic novel, and play + soundtrack (played live in between the sessions)

nice

thoughts about having the muc service also provide an http upload/jingle component or sth to upload files? For when the user server doesn't provide it.

Maybe there are times where it makes more sense to have it on the muc at all rather than the user's server.

pep.: I totally agree. It's also a minor privacy leak to see your private server's HTTP URL in a MUC

pep.: Not opposed. Authz via affiliation or such?

Sure

Zash: via occupancy?

Maybe the MUC domain should just allow the 0363 IQs to all JIDs that are joined to at least one MUC

Interesting that you could then upload the files to a MUC service and then post the links elsewhere

O(rooms) lookup?

MattJ, I guess that's "already an issue" anyway? you can create an anonymous user on most public servers and upload something there

Or even just any real account

Sure

If it's tied to a single room then it could automatically be broadcast on upload too

Good luck figuring out the race conditions between the sending client's message and that

https://brandimage.io/insight/XMPP?source=reddit

https://brandimage.io/insight/XMPP?source=hn

"A web page is slowing down your browser. What would you like to do?"

indeed, it may be slow weird on my old computer and tab-overloaded browsers I don't have this warning