jdev - 2025-02-03


  1. jonas’

    I read the readme and still don't understand what it does

  2. dwd

    I think it's connecting to multiple irc networks transparently, but I'm not sure you'd need to on xmpp, since we have heterogeneous federation (that is, muc rooms are hosted on different servers, but you can connect across federation, rather than on irc, where every server on a network is essentially operating identically).

  3. dwd

    Put another way, each xmpp server is its own administrative domain, whereas in irc, the entire network is (to a large extent) a single administrative domain.

  4. doge

    i. e. xmpp is centralized

  5. erik

    doge: *de*centralized

  6. qy

    mucs are centralised

  7. qy

    no DMUC xep ever bore fruit

  8. erik

    Per MUC, yes. Nothing can stop people from having a MUC, given the decentralization

  9. larma

    Nobody stops you from sending messages to multiple MUCs on different servers at the same time and then deduplicate at the receiver.

  10. qy

    Soni: woah i didn't realise it was you, you're on xmpp now?

  11. jonas’

    dwd, so just a "multi account" IRC client ;-D

  12. larma

    If you add the same origin-id to messages on the sender, deduplication actually becomes easy. You can even add some cryptographic proof to show that two users with the same nickname on different MUC servers are actually the same user.

  13. doge

    > Nobody stops you from sending messages to multiple MUCs on different servers at the same time and then deduplicate at the receiver. same way you could send messages to the same 1to1 chat from multiple accounts and deduplicate lol? I guess you can but at that point might as well just build a truly decentralized thing..

  14. qy

    > If you add the same origin-id to messages on the sender, deduplication actually becomes easy. You can even add some cryptographic proof to show that two users with the same nickname on different MUC servers are actually the same user. still needs some kind of dmuc/fmuc implementation

  15. dwd

    > dwd, so just a "multi account" IRC client ;-D Maybe? I might very easily have missed the point.

  16. larma

    qy: you can also use a bridge to bridge two XMPP MUCs

  17. dwd

    qy, There are multiple FMUC implementations, but we don't know if they interoperate.

  18. qy

    implementations? or xeps?

  19. dwd

    Implementations.

  20. qy

    Can you direct me to them? I thought there weren't any...

  21. doge

    Why is it that I only get read receipts and typing notifications on one device, seemingly randomly chosen? So for example, if I have dino and conversations online, only one of those will get those.

  22. lovetox

    Does the same happen with messages?

  23. doge

    strangely no

  24. lovetox

    Try Gajim it has XML console and you can see if you really don't receive it

  25. lovetox

    Or these clients for some reason don't show it

  26. lovetox

    If you don't receive it it's a server thing

  27. Kev

    Well, if the other end is doing resource binding, those messages don't have a body, so that affects carbonsing.

  28. doge

    if only multidevice wasn't a poor afterthought

  29. jonas’

    it's not an afterthought, but the initial thoughts (from 20+ years ago) for multidevice don't apply today anymore, and some clients still stick to them.

  30. lovetox

    Kev: it should not, all those stanzas are explicitly mandated in the carbons xep and it body does not matter

  31. lovetox

    Kev: it should not, all those stanzas are explicitly mandated in the carbons xep and body does not matter

  32. kalkin

    > Why is it that I only get read receipts and typing notifications on one device, seemingly randomly chosen? So for example, if I have dino and conversations online, only one of those will get those. Check your config.

  33. kalkin

    doge: it's interesting that you are the only one having unreliability issues. May be xmpp isn't for you.

  34. doge

    it takes two to have reliability issues

  35. kalkin

    doge: i have listened to your complains for about two month in various mucs. Im pretty convinced either you are the issue or you are just provoking people

  36. kalkin

    Especially the way you phrase your issues is toxic.

  37. squiddie

    > Especially the way you phrase your issues is toxic. what is so toxic about reporting bugs?

  38. kalkin

    squiddie: Nah, I'm disengaging here. Not my circus not my clowns.

  39. squiddie

    yeah, entertaining your own world of wishful delusions is much better, i agree

  40. qy

    first time speaking in this channel; says this

  41. squiddie

    doge, > Try Gajim it has XML console and you can see if you really don't receive it > Or these clients for some reason don't show it > If you don't receive it it's a server thing did you try this?...

  42. doge

    no

  43. squiddie

    btw how can it be a server thing really?

  44. squiddie

    a bug in server implementation?

  45. squiddie

    but yeah, at least it's not something like lost messages that were marked as sent...

  46. jonas’

    squiddie, so first of all: - this is a channel for developers, not for user support, so the question is basically off-topic unless doge is experiencing this while developing their own client or server - as kalkin pointed out, doge has been reporting the same issues for a *long* time now, and AFAIK, has never reported them with enough info to reproduce them to any upstream project.

  47. jonas’

    squiddie, that, combined with blanket adversarial statements against XMPP in general is something I am ready to classify as toxic.

  48. squiddie

    honestly i would classify any software that has XML in it as toxic... as a person who worked with xml

    🍿 2
  49. squiddie

    i mean, if protocol devs show toxicity to its users, it would be reasonable from users to show same toxicity to protocol, clients, whatever... so doge kinda has the point...

  50. squiddie

    i hope we will witness any force emerging that is going to change the status quo in software development..

  51. squiddie

    maybe the only issue with xmpp is just xml...

  52. kalkin

    I'm using conversations right now so I can't see if squiddie only joined after my answer to doge?

  53. qy

    > honestly i would classify any software that has XML in it as toxic... as a person who worked with xml 🍿

  54. mathieui

    kalkin, yes they did

  55. kalkin

    squiddie: doge you are an asshole. Go troll somewhere where it's appropriate

  56. Kev

    And calling people names isn't appropriate for here. Please don't.

  57. doge

    > a bug in server implementation? Not even a bug. I don't think the specification mandates that the server must deliver to all connected devices. It's just bad ideas from the get-go.

  58. kalkin

    Kev: ok.

  59. Kev

    > > a bug in server implementation? > Not even a bug. I don't think the specification mandates that the server must deliver to all connected devices. It's just bad ideas from the get-go. You are welcome to that thought, but this channel is for development discussions, so this doesn't seem constructive here.

  60. Heru

    Hello everyone, thank you to the admin who manages this conversation, allow me to introduce myself.

  61. Heru

    I am from Indonesia want to learn xmpp and I am interested in this

  62. Heru

    In Indonesia the xmpp project is not available, #I want to develop xmpp so that people in my country can enjoy xmpp, so please guide me, thank you

  63. qy

    open source code does not respect nation boundaries

  64. Heru

    So XMPP is truly open source software that can be developed by any country.

  65. Cynthia

    yes

  66. Cynthia

    that's the point of open source

  67. Heru

    Thank you for the explanation, it really helped me a lot.

  68. Soni

    qy: uh... sorry, who are you? >.<

  69. Soni

    (we've been on xmpp for a while but this is the first time we join a, MUC? is that what this is called? (what does it stand for, anyway?))

  70. jonas’

    (multi-user chat)

  71. Soni

    (tho we will note that we're using bitlbee because ofc we are)

  72. doge

    (((multi))) (((user))) (((chat)))

  73. Soni

    thanks

  74. Soni

    so given that xmpp has a bunch of administrative domains what happens if you're on say sleeping.town and your instance is banned from say muc.xmpp.org, or vice-versa? in theory you wouldn't be able to use that room, right? but what if you instead had accounts across multiple instances? (also, can an instance ban, like, specific users in a MUC, based on their instance? we don't know how MUCs work tbh, or XMPP for that matter, our experience with federated systems

  75. Soni

    is mostly mastodon)

  76. jonas’

    so many questions

  77. jonas’

    and some of these would be better suited in xsf@muc.xmpp.org, where the standard itself is discussed (rather than implementation work)

  78. jonas’

    and some of these would be better suited in xmpp:xsf@muc.xmpp.org?join , where the standard itself is discussed (rather than implementation work)

  79. jonas’

    1) you are correct, if muc.xmpp.org blocks sleeping.town, you cannot join with a sleeping.town account to any MUC there. 2) it's called multi-account clients, and indeed most XMPP clients support more than one account out of the box (poezio being one notable exception) 3) yes, most MUC implementations allow banning an entire domain.

  80. jonas’

    1) you are correct, if muc.xmpp.org blocks sleeping.town, you cannot join with a sleeping.town account to any MUC there. 2) it's called multi-account clients, and indeed most XMPP clients support more than one account out of the box (poezio being one notable exception) 3) yes, most MUC implementations allow banning an entire domain (in addition to banning individuals).

  81. Soni

    yeah, we guess "federating the client" might be more of a discussion related to the standard than purely implementation

  82. Soni

    but multi-account clients today do not support combining multiple accounts and "crossposting" actions between them (and deduplicating on the other side)

  83. jonas’

    no, and personally I don't see value in that.

  84. jonas’

    seems like lots of overhead for little gain (except ban evasion, which ... well, I don't want to see well supported anyway :))

  85. Soni

    there's value in that on mastodon. and to some extent on certain IRC networks (and possibly DMUCs if those existed, tho apparently they don't). if MUCs are store-and-forward, and if sleeping.town admins can't selectively hide users in an muc.xmpp.org room from sleeping.town users, then yeah there's no point to doing it on xmpp.

  86. Soni

    (or to put it negatively: "is it possible for admins to gaslight their xmpp instance users? and if so, the value of this is precisely in mitigating that issue")

  87. jonas’

    well, an admin can do all kinds of nasty things. but XMPP is built around a model where you have a baseline level of trust in your server admin.

  88. jonas’

    like selectively dropping messages in a non-OMEMO conversation is definitely possible.

  89. jonas’

    but if you have such a relationship to your server admin, you probably shouldn't trust them with relaying your conversations in the first place.

  90. Trung

    if you have an account for bussiness.com I don't think anyone would want to have the same messages sending out from drunk.org

  91. Soni

    Trung: we mean... maybe you want to link those?

  92. Soni

    (it would have to be opt-in, yeah)

  93. Trung

    I'm sure technically can be done but I don't think that's the reason humans have multiple accounts. Chat account or bank account or whatever else account.

  94. Trung

    bit odd ………

  95. Schimon

    Greetings to one and all!

  96. Schimon

    Is there a server with a high maximum allowed pubsub node items per node?

  97. moparisthebest

    Schimon: I think all of them are configurable

  98. singpolyma

    If you're looking for perm pubsub component maybe run the libervia one

  99. Schimon

    moparisthebest. Yes. But not all have the same amount of maximum allowed items. For example, CanChat allows 255 items.

  100. Schimon

    singpolyma. By "perm" do you mean unlimited?

  101. jonas’

    Schimon, I don't think public servers have much higher limits, because there are issues around that.

  102. Schimon

    jonas’. movim.eu appears to allow thousands of items.

  103. edhelas

    Thanks to the power of ejabberd and Postgresql !

  104. Schimon

    I am intending to make Blasta compatible with Libervia and Movim, and Blasta is designed for annotations (i.e. publishing thousands of items).

  105. Schimon

    > Thanks to the power of ejabberd and Postgresql ! edhelas. I have failed to enjoy that limit on your server. I do not know whether it has been changed or not.

  106. Schimon

    > Thanks to the power of ejabberd and Postgresql ! edhelas. I have failed to enjoy a limit beyond 255 on your server. I do not know whether it has been changed or not.

  107. Schimon

    > Thanks to the power of ejabberd and Postgresql ! edhelas. I have failed to set a limit beyond 255 on your server. I do not know whether it has been changed or not.

  108. Soni

    what is the opposite of a MUC called? is that called a SUC?

  109. jonas’

    it has no name

  110. jonas’

    (no official name anyway)

  111. Soni

    okay, we're gonna call it a SUC then, for lack of a better name >.<

  112. Soni

    hmm we wish this client allowed us to write multiline messages...

  113. Soni

    anyway we do wanna address the comments about ban evasion, especially with regards to SUCs

  114. heru712

    hello

  115. heru712

    how to add city in this app

  116. Heru looperman

    how to add contact in this app

  117. moparisthebest

    > what is the opposite of a MUC called? is that called a SUC? Soni: 1:1 or PM (private message) or DM (direct message) are terms I've seen

  118. moparisthebest

    Heru looperman: we don't know what app you are using, you should ask in their support channel

  119. moparisthebest

    Soni: wouldn't a "SUC" be a Single User Chat or you just talking to yourself? :P

  120. moparisthebest

    I find chats are usually better with at least 2 people but you do you I guess

  121. Soni

    well, single as in one to one :v

  122. Soni

    sorry we needed some food, we'll talk about the thing Eventually^TM

  123. doge

    Actually, it's called a DUC

  124. doge

    double user chat

  125. qy

    _Double User Text CHat_

  126. theTedd

    _TwO Users CHatting_

  127. Soni

    anyway, consider this scenario: we have userA@instanceA.example, userB@instanceB.example, adminA@instanceA.example, adminB@instanceB.example. for some reason userA and userB are friends, but adminA and adminB hate eachother. so userA can't add userB. this should be recognized as a problem. traditionally you'd work around the problem by having userA@instanceB.example (or vice-versa), with a separate contact list. but we could do better than that. why have a

  128. Soni

    separate contact list? why not allow the contact lists to be, how can we put it, nomadic? interchangeable?

  129. Soni

    as a separate concern, let's say adminA@instanceA.example bans userB@instanceB.example, and userB also has an alt at userB@instanceC.example. traditionally, adminA@instanceA.example would not know about it! with account linking, they can *more effectively* ban userB!

  130. Soni

    (and from there you can try mixing aspects of the two scenarios to figure out all the other properties you get when you "crosspost" every action between multiple accounts)

  131. Soni

    the biggest pain point is dealing with MUCs and deduplication, but if there's anyone we'd trust to be capable of figuring that out, it's y'all.

  132. moparisthebest

    > anyway, consider this scenario: we have userA@instanceA.example, userB@instanceB.example, adminA@instanceA.example, adminB@instanceB.example. for some reason userA and userB are friends, but adminA and adminB hate eachother. so userA can't add userB. this should be recognized as a problem. traditionally you'd work around the problem by having userA@instanceB.example (or vice-versa), with a separate contact list. but we could do better than that. why have a Soni: I get this kind of admin entire instance banning is common in fediverse etc, but it's not in XMPP. Additionally here (unlike others) it's trivial for everyone to run their own server, so it feels a lot like you are inventing problems that don't exist just to try to work around them?

  133. Soni

    indeed, it is common in fediverse etc. but we can't get fediverse *client* developers to take it seriously. so... we've given up, honestly.

  134. Soni

    it's still a problem we want to see solved, you never know where these kinds of solutions can be applied (multicast systems? there are some folks under a project called "librecast" that might have use for this kind of solution), even if we can't use it where we wanna use it (aka the fediverse)

  135. Soni

    (s/aka/i.e./)

  136. theTedd

    Something something proxy something

  137. moparisthebest

    It's not a problem in XMPP though, which makes "solving" it kind of impossible?

  138. moparisthebest

    Or trivial, considering the solution is running your own server

  139. moparisthebest

    Depends on your PoV I guess

  140. Soni

    how so...? specifically, the problem we're trying to solve is how to deal with "a client with "crossposting" features", and we believe that *should* be applicable to xmpp somehow?

  141. Soni

    we don't know any clients that do that, but we don't see anything that stops you either

  142. theTedd

    The question is more "is this a problem anyone is realistically facing?" which then leads to the need for a solution

    ☝️ 1
  143. moparisthebest

    > The question is more "is this a problem anyone is realistically facing?" which then leads to the need for a solution ☝️

  144. qy

    the answer is to introduce bouncers, right?

  145. theTedd

    That would be the simplest

  146. Soni

    bouncers?

  147. theTedd

    ServerC is not banned, so messages between A and B go via C instead

  148. Cynthia

    hi

  149. theTedd

    Greetings

  150. Soni

    we're unsure how bouncers help?

  151. Cynthia

    Soni: a DHT?

  152. Soni

    Cynthia: no.

  153. Cynthia

    ah

  154. Cynthia

    why?

  155. Cynthia

    if you know what userB's key is, of course

  156. Soni

    we're not exactly anti-p2p but we do enjoy the exercise of trying to see how far we can approach the benefits of p2p without using actual p2p

  157. moparisthebest

    > ServerC is not banned, so messages between A and B go via C instead We already have this implemented in XMPP btw, maybe that's your fix Soni

  158. Cynthia

    that doesn't make sense, but sure

  159. moparisthebest

    If user a and user b can't contact each other directly because their servers have banned each other, they can join a muc on any other server and message each other there or DM each other

  160. Soni

    here's an example: we make a tool called "ganarchy", which is similar to another tool called "radicle", which is a p2p git forge. but ganarchy uses no p2p.

  161. Soni

    (it also uses significantly less cryptography and there's no real risk of losing keys)

  162. Cynthia

    that just sounds like centralization

  163. Cynthia

    but maybe what moparisthebest said could help

  164. Soni

    moparisthebest: oh, wait, so users in mucs act like their own accounts, separate from the original account?

  165. theTedd

    The MUC would be hosted on 'serverC' so neither A not B see any such connection between A and B

  166. theTedd

    The MUC would be hosted on 'serverC' so neither A nor B see any such connection between A and B

  167. theTedd

    The MUC would be hosted on 'serverC' so neither serverA nor serverB see any such connection between A and B

  168. Cynthia

    what if the MUC admin bans user A or user B's server

  169. Soni

    yeah but... they'd still see the handle, no?

  170. theTedd

    Not for semi-/anon MUC

  171. theTedd

    > what if the MUC admin bans user A or user B's server Then they need another 'serverC'

  172. moparisthebest

    > moparisthebest: oh, wait, so users in mucs act like their own accounts, separate from the original account? Uh, kinda, the muc server relays messages for them so their servers can't see each other's real addresses

  173. Soni

    alright, so, if we're understanding correctly... bouncers are an effective way to ban evade?

  174. theTedd

    Masking your origin is an effective way to evade a ban based on filtering on your origin

  175. Soni

    point being... why wouldn't our approach be better?

  176. theTedd

    Is either better or worse in any useful respect? One exists and is usable today, the other is not.

  177. Soni

    one is straight-up ban evasion, the other cannot be reasonably considered ban evasion unless you consider "simply not using the server where the ban exists" as ban evasion

  178. theTedd

    It's only authentic ban evasion if it comes from the _Évasion_ region of France, otherwise it's just sparkling proxy usage

  179. theTedd

    If your intent is to evade the effects of a ban then it's ban evasion, regardless of how you achieve it; if your only defense is to argue over semantics, you've already lost the argument

  180. Soni

    the point of a ban is to restrict the contents that go over a server, generally speaking. so, using a different server is quite the opposite of ban evasion - it is being respectful of a ban.

  181. theTedd

    I'm sure whoever instituted the ban will be very understanding and agree with you wholeheartedly

  182. Soni

    what are they gonna do? force us to... use the other server?

  183. theTedd

    Please do that and then we can focus on solving useful problems

  184. Heru looperman

    I am using conversation app and I am having trouble adding contacts

  185. kalkin

    Heru looperman: use the conversation support chat

  186. kalkin

    Heru looperman: xmpp:conversations@conference.siacs.eu?join

  187. Heru looperman

    kalkin: ok i'll try, thanks for the suggestion

  188. mathieui

    Soni, so after reading your problem definition, I feel like this, as moparisthebest said, is not really a problem in XMPP, and therefore not something many people would want to direct resources at. I do see the issue on the fediverse, but in my view the way to solve this is by having better account portability (i.e. cleaner export/import, a way to keep posts, etc), rather than try some wizardry to circumvent the policies set by the admin.