jdev - 2021-04-19

  1. Sam

    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

  2. moparisthebest

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

  3. Sam

    I'll push it up somewhere

  4. Sam

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

  5. Sam

    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.

  6. Sam

    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.

  7. lovetox

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

  8. lovetox


  9. lovetox

    which the authors claim is privacy friendly and scaleable

  10. lovetox

    i guess only phone clients care about that

  11. Zash

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

  12. Zash

    Probably way harder if you include other identifiers.

  13. mathieui

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

  14. mathieui

    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

  15. mathieui

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

  16. Zash

    Not the same problem I guess

  17. mathieui

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

  18. Zash

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

  19. mathieui

    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

  20. mathieui

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

  21. Zash

    As in, no federation?

  22. Zash

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

  23. Zash

    Not totally unlike the Quicksy directory

  24. mathieui

    Zash, well, except worse

  25. mathieui

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

  26. mathieui

    that does not help you resolve a JID from another element

  27. mathieui

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

  28. mathieui

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

  29. Zash

    What if...

  30. Zash

    You do that, but p2p

  31. mathieui

    Error: not enough information

  32. Zash

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

  33. Zash

    Assuming PSI lets you do that without leaking

  34. mathieui

    that could work

  35. mathieui

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

  36. pulkomandy

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

  37. mathieui

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

  38. mathieui

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

  39. mathieui

    that is kind of the point

  40. Zash

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

  41. mathieui

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

  42. Zash

    Hm, is it useful then?

  43. mathieui

    ah, apparently they do know about the intersection

  44. mathieui

    which is obviously a big no for p2p then

  45. Zash


  46. Zash

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

  47. mathieui

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

  48. mathieui

    even with contacts

  49. pulkomandy

    especially with contacts I'd say?

  50. mathieui

    pulkomandy, I tend to appreciate my contacts :p

  51. Zash

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

  52. pulkomandy

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

  53. mathieui

    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

  54. mathieui

    send whatever JID

  55. mathieui

    (if some contacts matches)

  56. mathieui

    which is yet another attack

  57. Zash

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

  58. pulkomandy

    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"

  59. mathieui

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

  60. mathieui

    (for centralized messengers of course)

  61. Zash

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

  62. mathieui

    Zash, potato farming

  63. Zash

    true fact

  64. MattJ

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

  65. MattJ

    Because if they do that, they get all registered JIDs

  66. MattJ

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

  67. Zash

    Snikket Circle stuff FTW

  68. jonas’

    I hear the limits worked really well for signal

  69. MattJ

    Snikket FTW

  70. jonas’


  71. jonas’

    (say all the folks involved with snikket)

  72. MattJ


  73. Zash


  74. MattJ

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

  75. mathieui


  76. jonas’

    and a more manual, to be fair

  77. mathieui

    It is ethically better but still a higher level of entry

  78. mathieui

    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?

  79. Zash

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

  80. mathieui

    that’s probably not a very common use case

  81. jonas’

    mathieui, it won’t work with circles at least

  82. jonas’

    as those don’t federate well at this time

  83. jonas’

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

  84. Zash

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

  85. MattJ

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

  86. jonas’

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

  87. MattJ

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

  88. jonas’


  89. MattJ

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

  90. jonas’


  91. jonas’

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

  92. pulkomandy

    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

  93. pulkomandy

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

  94. Zash

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

  95. Sam

    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

  96. Sam

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