jdev - 2024-06-03

  1. MSavoritias (fae,ve)

    is there a way for a user to subscribe to another user's MUC MAM archive? reading the MAM XEP i think this should be possible since the MUC MAM is supposed to be a seperate archive and it doesnt specify what entities interact. so one user can just act as a temporary node/server and another user can act as a reciever

  2. MSavoritias (fae,ve)

    i have a specific architecture in mind and i am wondering if anybody has done this before

  3. singpolyma

    No sure what you mean by "subscribe to" but you can send a mam query to any jid yes

  4. jonas’

    MSavoritias (fae,ve), there is no such thing as a "user's MUC MAM archive"

  5. jonas’

    the MUC MAM is no the MUC server, not on the user's server.

  6. MSavoritias (fae,ve)

    right. subscribe i meant that you use the same MUC MAM all the time to query or the same MAMs

  7. jonas’

    I don't follow

  8. t

    > I don't follow i got a notification from this for some reason

  9. t

    on dino

  10. t

    ah bad nickname

  11. singpolyma


  12. taba

    we're so back

  13. MSavoritias (fae,ve)

    > I don't follow a bit longer explanation for context I was thinking that in a p2p context and group chats specifically its wasteful for everybody to ping everything. So I was thinking to implement somekind of "multicast" system. Basically the group chat expands into a tree and you get the archive from your nearest neighbor instead of pinging everybody. so for that you would need to get the messages from your nearest neighbor through some kind of way. I was thinking of MAM.

  14. MSavoritias (fae,ve)

    and since singpolyma said that i can just query any jid it should just work

  15. jonas’


  16. MSavoritias (fae,ve)

    probably I am looking into every user hosting some kind of "instance" of a room, not sure on that yet. So the architecture should be compatible with you get the MAM from some kind of MUC server

  17. jonas’

    sounds like matrix?

  18. jonas’

    or maybe fmuc

  19. MSavoritias (fae,ve)

    not sure on this tho because it makes things very messy

  20. jonas’

    it does.

  21. MSavoritias (fae,ve)

    > sounds like matrix? heh maybe. i mean i am thinking of a DAG for ordering of messages independent of time. or some kind of message Graph like Brumble has from Briar

  22. jonas’

    that does sound like Matrix.

  23. MSavoritias (fae,ve)

    > it does. yeah and like i dont see why everybody needs to host the room

  24. MSavoritias (fae,ve)

    or maybe i am missing something

  25. MSavoritias (fae,ve)


  26. MSavoritias (fae,ve)

    > that does sound like Matrix. it does. but i am hoping to make it space efficient

  27. jonas’

    as much as I dislike Matrix, I'm sure the protocol is a result of some smart people following logical reasoning from sensible assumptions, and if you start out with a DAG, there may be actually good reasons why pruning is hard.

  28. MSavoritias (fae,ve)

    good point.

  29. jonas’

    might be worth taking some knowledge from the matrix folks at some conference to learn the reasoning

  30. MSavoritias (fae,ve)

    i could always do it based on git like jami :P

  31. MSavoritias (fae,ve)

    > might be worth taking some knowledge from the matrix folks at some conference to learn the reasoning yeah i wanna read the briar and matrix rationale on this

  32. MSavoritias (fae,ve)

    > probably I am looking into every user hosting some kind of "instance" of a room, not sure on that yet. So the architecture should be compatible with you get the MAM from some kind of MUC server coming back to this yeah this is an antipatern. because it means your connection/node is visible to all the people in the room. so at the very least you should have the option to host or not

  33. moparisthebest

    Also since you no longer have one source of truth for message history, all messages have to be cryptographically signed to prove authenticity and even then are subject to reordering and dropping by an attacker, and that's if everything goes right

  34. MSavoritias (fae,ve)

    of course :) but i didnt want into all the architecture things i am thinking

  35. MSavoritias (fae,ve)

    of course :) but i didnt want to get into all the architecture things i am thinking

  36. moparisthebest

    MSavoritias (fae,ve): have you looked at nostr ? I tend to think that architecture is better suited for this kind of thing

  37. MSavoritias (fae,ve)

    why do you think its better?

  38. MSavoritias (fae,ve)

    or better phrased: what does xmpp lack/cant be implemented

  39. MSavoritias (fae,ve)

    the only claims i have read of xmpp being not good for this is from secushare which says that xmpp is terribly inneficient

  40. moparisthebest

    Well not that at all, that's silly :)

  41. moparisthebest

    But if you are trying to create an architecture where every client signs all their messages, and can grab them from any other client/server (like, there is no single source of truth), that's literally nostr's architecture, we no longer need domains and all this stuff we have with XMPP

  42. MSavoritias (fae,ve)

    ah. well true i dont plan to use domains but use GNS instead. the thing with Nostr is that you end up re-solving all the problems xmpp had to deal with

  43. MSavoritias (fae,ve)

    even if you end up not using xmpp as in tcp/ip xmpp

  44. MSavoritias (fae,ve)

    which tbh i dont think it is that incompatible. its surprising how flexible it is

  45. MSavoritias (fae,ve)

    MAM and jids for example work as is

  46. moparisthebest

    It could of course use XMPP XML which is way more sane than layers of escaped json in json like nostr, I'm just saying it roughly sounds identical to nostr architecture-wise so maybe there's something to learn there

  47. MSavoritias (fae,ve)

    ah yeah for sure

  48. MSavoritias (fae,ve)

    tbh the architecture is probably exactly the same as briar except xmpp based and over GNS

  49. moparisthebest

    So firing from the hip here, what if we had XMPP shaped like nostr ? No "servers" like there are now, no passwords, no presence, jids could just be "publickey.xmkeyp" (sharing a suffix to uniquely identify these would be nice, onion-style) Your client(s) would communicate with (multiple) relays (the new servers, but they only accept incoming connections, never make outgoing ones) over s2s, could just reuse TLS/quic, but really wouldn't need any authentication of the stream/connection at all (or it could be optional), instead it just validates each individual message has a valid signature sending a message would be signing it, optionally encrypting it if it's private, and publishing to N relays recieving a messaging would be asking N relays for messages you are interested in, probably just subscribing to some pubsub nodes, maybe asking with MAM

  50. Zash

    https://xmpp.org/extensions/xep-0174.html + some metadata and routing overlay ?

  51. moparisthebest

    This would let you reuse a lot of existing XMPP code/clients/servers, it could also be fine for mobile, because you could have 1 server (that optionally you run yourself) that could handle the publishing/subscribing to the N servers, everything could still do CSI etc... 🤔

  52. MSavoritias (fae,ve)

    so you actually have servers :P

  53. moparisthebest

    Everything does, some just call them relays

  54. Zash

    Servers you didn't choose.

  55. Kev

    It's not the cloud, it's a very naughty boy.

  56. moparisthebest

    In nostr and this architecture you *do* choose the relays

  57. MSavoritias (fae,ve)

    what would have for routing tho? libp2p? for c2s i mean

  58. moparisthebest

    But your identity is not tied to them and if half of them go down you can still communicate

  59. moparisthebest

    There is no c2s

  60. MSavoritias (fae,ve)

    i mean the client to relay

  61. moparisthebest

    You choose the relays you connect to, then you just connect directly to them

  62. rom1dep

    Re: P2P, wasn't there a XEP recently about it?

  63. rom1dep

    Here it is https://xmpp.org/extensions/xep-0415.html

  64. rom1dep

    (and damn, 2019 is "recently" in my mind)