jdev - 2021-04-19

Thanks; I got curious and gave it a shot so I want to steal your tests and also see if you're doing anything XML-wise that I don't know about and need to fix

Sam, is your implementation public? I'm equally curious :)

I'll push it up somewhere

moparisthebest: https://pkg.go.dev/mellium.im/xml

It's a bit different from yours, right now it only splits a byte stream on possible XML tokens. It may split out things that are invalid, but I don't believe it will ever split something that should be valid incorrectly. Later maybe I'll add a higher level thing that actually parses tokens, expands self-closing tags, etc.

Although I should also say that I wouldn't use this as the basis for the actual parser probably. You wouldn't want a parser to consume a giant chunk of text where right at the beginning it could have realized it was invalid, you'd want to error as soon as possible, so it would copy some of the splitters work but not use it exactly because the parser can error, the splitter can't.

hm i just read an article on hackernews, and in a comment someone mentioned this protocol for contact discovery

https://contact-discovery.github.io/

which the authors claim is privacy friendly and scaleable

i guess only phone clients care about that

From the prominence and frequency of the word 'mobile', sure sounds like it'll be about phone numbers, yeah.

Probably way harder if you include other identifiers.

the protocols they propose do not seem to be linked to phone numbers though

from a quick look, it’s bloom filters with crypto sprinkled on top, which is nice for the purpose of not sending your address book to the server, and also the enumeration attacks they found

not really much help for discovery in a federated setting as far as I understand it

Not the same problem I guess

(both client and server need to know the phone numbers of the dataset)

Wasn't there cryptomagic that let you query an encrypted database? I definitely saw a video presentation about that once.

I mean, it *can* be useful if implemented to find contacts on a server, by e.g. querying phone numbers or emails against whatever is in the vcard

but I don’t see it going much further than this

As in, no federation?

So the solution is to centralize it, like Matrix with their Identity Server stuff.

Not totally unlike the Quicksy directory

Zash, well, except worse

that’s "Private Set Intersection", what you get as a result, is "which elements are in both of these sets"

that does not help you resolve a JID from another element

(but I like the idea though, did not know about it)

(I would happy to be proven wrong about the uses for xmpp contact discovery, I’m not a cryptographer :p)

What if...

You do that, but p2p

Error: not enough information

As in, ask your contacts if they have the JIDs of anyone in your phonebook

Assuming PSI lets you do that without leaking

that could work

it does not leak info, as far as I can tell

I'm more confortable sending my contact list to Google or some other supposedly big evil company than sending them to all my contacts

but there needs to be a negociation and quite a bit of computation involved

pulkomandy, the contact does not know your contact list :p

that is kind of the point

Tho they would, by necessity, get the intersection of the contact lists?

I believe they do not know what is in the intersection as well, but I would need to read one more paper for that

Hm, is it useful then?

ah, apparently they do know about the intersection

which is obviously a big no for p2p then

obviously?

Is "hey can you give me the JIDs of our mutual contacts" a bad thing?

well, it leaks your social graph, which is not necessarily what people would want to share

even with contacts

especially with contacts I'd say?

pulkomandy, I tend to appreciate my contacts :p

Eh, can't think of anything better than the stuff Snikket is doing then.

but not everyone has an easy life like that :) good for you if you can

also you still have the issue of "the numbers matched, here are the JIDs", and the JID part is not cryptographically secure so anyone could like

send whatever JID

(if some contacts matches)

which is yet another attack

Eh, just put your JID in your $socialnetwork profile and call it a day.

yes, I think I'm going to stay at "automatically discovering contacts is bad for your privacy or that of your contacts and it's better to not do it"

pulkomandy, well, the privacy solution would be to have one address book per "mobile application of the week" + this PSI protocol

(for centralized messengers of course)

Where's the optimal balance between uploading your phonebook to the cloud, and staring at an empty contact list?

Zash, potato farming

true fact

Any scheme you come up with has to defend against an actor claiming to have every phone number in their address book

Because if they do that, they get all registered JIDs

A centralized service can add limits, a decentralized one typically can't

Snikket Circle stuff FTW

I hear the limits worked really well for signal

Snikket FTW

+1

(say all the folks involved with snikket)

:)

NO BIAS, I PROMISE!

Invites and JID sharing are a more polite way of doing the same thing as automatic contact discovery anyway

yes.

and a more manual, to be fair

It is ethically better but still a higher level of entry

MattJ, I haven’t looked at that stuff too much, but is there a way to reply to an invite with "I already have an account at ***@example.com, I am adding you now" in some kind of protocol-y way?

Well if you wanna do the dark engagement and addiction building things...

that’s probably not a very common use case

mathieui, it won’t work with circles at least

as those don’t federate well at this time

I don’t have a good idea how to span circles across services yet

There's that pre-authed contact invites with optional IBR support

mathieui: yes, the invite token has two dimensions - one is to register an account, the other is a preauthed roster subscription

yep, that one exists, but it doesn’t support circles.

That's fine, circles are for users within a single service

mmhm

Maybe we can change that one day, but they're not everything

yes

I’d like to be able to span them, but they’re already really good as is

let's just offer new XMPP users a set of business cards with their JID on it (and a qrcode or something) then they can choose who they share it with? sometimes low-tech solutions are good

(or maybe qrcode isn't lowtech. but fitting a JID in a barcode is hard)

We had those "Hello, my JID is" stickers....

Reminder that tomorrow is the XMPP Office Hours! This week I'm giving an intro to XMPP for new XMPP developers. However, if you're an experienced dev I'd love feedback! https://wiki.xmpp.org/web/XMPP_Office_Hours

wow, that's a lot of messaging clients: https://wiki.archlinux.org/index.php/List_of_applications#Instant_messaging_clients