XSF Discussion - 2020-05-20

  1. pep.

    eevvoor, done

  2. eevvoor

    pep. :)

  3. Wojtek

    oh... here we go again :DD @eevvoor we are not specifically against (where did you get that from) but we simply won't drop just like that because there are other factors at play; *most likely* we will address it (0372?) but it will take some time. Besides, 0372 has it's own issue ("A begin attribute is used to mark the index in the body of the referring message of the first character (TODO: define character appropriately)", erm... :-) ) so it will take some time. and in case of other clients it boils down to having issue with detecting `@` + nick.

  4. pep.

    Wojtek, see https://xmpp.org/extensions/xep-0426.html

  5. pep.

    372 hasn't been updated, but that's probably the safest bet

  6. eevvoor

    Wojtek, ah you are here too, that is convenient.

  7. Wojtek

    it's convenient but then we have discussion here and on github and we are rehashing this issue again ;-)

  8. eevvoor

    > and in case of other clients it boils down to having issue with detecting `@` + nick why, we would not have an @ then

  9. pep.

    I'd say you should lock the issue :x

  10. eevvoor

    pep. lock down for corona issues? :D

  11. pep.


  12. eevvoor

    anyhow, I do not mind, I am not a beagle IM user.

  13. eevvoor

    just my two cents ...

  14. pep.

    > and in case of other clients it boils down to having issue with detecting `@` + nick. And enforcing "@" on all the ecosystem, introducing more places where body needs to be parsed, etc. etc. :)

  15. Wojtek

    @pep. I have pinned it :-)

  16. pep.


  17. Wojtek

    yeah, this one and http-upload got a lot of attention and complaining so it makes sense to pin them.

  18. eevvoor

    never heard of pinnin, what does this github language word mean

  19. pep.

    go to https://github.com/tigase/beagle-im/issues and observe

  20. Wojtek

    the issue is displayed at thet op of the list of issues in repository

  21. eevvoor

    never heard of pinning, what does this github language word mean?

  22. Wojtek

    we are not enforcing it, but other clients could check for mentions not only on `\w<nick>\w` tbh, I'm not sure that incidental mentions notifications are all that great

  23. eevvoor


  24. eevvoor

    Wojtek, yeah we discussed that when ingoj opened the issue.

  25. eevvoor

    Some of us "use" the nick mentioning as filtering by changing nick name.

  26. pep.

    Wojtek, I don't disagree with the fact that using regex in body to match nicknames is meh. That's mostly historical though.. (damn IRC)

  27. pep.

    I don't think it's an excuse to introduce even more sigils

  28. eevvoor

    But that is more hacking than noob friendly usablility, of course ...

  29. pep.

    I think the whole debate around "using @ or not using @" is pointless

  30. eevvoor


  31. pep.

    Please don't pollute the wire any more :x

  32. Wojtek

    let me repeat myself: "Current situation is is not ideal" :-)

  33. pep.

    Wojtek, sure

  34. Wojtek


  35. eevvoor

    Separating content from layout is important. @ is not useful here.

  36. pep.

    eevvoor, "@" is irrelevant, not "not useful" :P

  37. Wojtek

    @pep. btw. we do support displaying markdown messages - oh the horror ;-)

  38. eevvoor

    yes :)

  39. pep.

    Wojtek, you make me sad

  40. eevvoor


  41. pep.

    markdown and not styling, right?

  42. eevvoor

    gfm markdown or markdown+raw XD

  43. pep.

    (it's the same horror to me anyway, assuming you've done it the same way)

  44. Wojtek

    we don't allow formatting - we just try to display the intent when received because that seems to make sense

  45. pep.

    the intent?

  46. eevvoor

    the semantics :D

  47. Wojtek

    Sometiems you want to **stress** something

  48. eevvoor

    @ is also just a layout semantics

  49. pep.

    or @@stress@@ something

  50. Wojtek

    I've used `**` and `__` in the usenet days, way before markdown was a thing :-)

  51. pep.

    I'm too young for usenet :x On IRC I used * and _ sometimes (not doubled), but then again not just to emphasize, for other uses too

  52. pep.

    I've also used "/"

  53. pep.

    But IRC is what it is, I don't want to reintroduce these horrors in XMPP

  54. moparisthebest

    It's not just IRC though, it's all text communication back to the beginning of the internet, also before my time

  55. eevvoor

    yes mail too

  56. eevvoor

    btw in mails you also mention people with @ ;)

  57. pep.

    Do you?

  58. eevvoor

    lots of people do

  59. pep.

    wut, why..

  60. pep.

    I don't know of any client that interprets that

  61. pep.

    (but I don't know of many clients)

  62. eevvoor

    no of course not

  63. eevvoor

    it is the humans who interpret that.

  64. eevvoor

    you do not have nicks in mails, it is just for structuring the paragraphs: this is imrportant for @person1, person2 and thtat for @personx

  65. pep.


  66. pep.

    Wojtek, your example in the issue is not fair as you only cite platforms that do not federate and don't have various client implementations

  67. Wojtek

    erm, mastodon is 3rd ;-)

  68. pep.

    ah mastodon

  69. pep.

    Well it's the only one

  70. Wojtek

    eevvoor - you see, I forgot email from my list, and this is just 'hoomans doing hooman things'... it's not for interpretation, just an indication. And IMHO it's better than corporate quotations with using colours and other formatting, which breaks completely when you are forcing plain-text view...

  71. pep.

    fwiw, re colors and weird formatting, I do blame email clients..

  72. pep.

    I also blame email for sure and the mess they've made with html

  73. Wojtek

    what are other global and popular federated networks? you could say e-mail, but many argue that e-mail is stuck in the prehistoric times and it's impossible to move it forward or introduce anything there because... it's federated

  74. pep.

    popular I don't know, but there's also Matrix. But they also have only one implementation anyway.. (:P)

  75. Wojtek

    they do seem to use `@` as well: https://github.com/matrix-org/matrix-doc/blob/master/specification/modules/mentions.rst ;-) (this seems a bit awful though...)

  76. pep.

    fwiw matrix also seems to have a separate representation for its html thing

  77. pep.

    Wojtek, right, so it's html, not in the text :x

  78. pep.

    I was curious how they were doing that

  79. Wojtek

    well, it's still in text... formatted text

  80. Wojtek

    seems like multi-part e-mail though

  81. Wojtek

    I wonter if they allow sending payloads without `body`

  82. pep.

    "body": "Hello Alice!"

  83. pep.

    where in the text?

  84. pep.

    I don't know. I don't think xhtml-im did

  85. pep.

    fallback body blah blah

  86. pep.

    Anyway I think the discussion on "@" is irrelevant. Some platforms may very well use it and some XMPP clients will reuse it for sure and that's fine. The question is how :p

  87. !XSF_Martin

    > wut, why.. > I don't know of any client that interprets that FYI Of you write an @ in MS Office Mail/Outlook whatever it is called that days you can cycle through the the people on the current distributor. So they use it like Tigase/Beagle it seems.

  88. MattJ


  89. MattJ

    Summary: they intend to introduce identities that are not phone numbers (lack of which is one of the main complaints against Signal by the very market segment they target)

  90. MattJ

    So they need to store a roster, but they don't want it on the server (unencrypted)

  91. mathieui

    Aren’t they only hinting it for now?

  92. MattJ

    If they encrypt it on the device before uploading, the user would lose access to it if they lost their device with the encryption key

  93. MattJ

    Publicly hinting, and putting this effort in? It's clearly one of their priorities

  94. MattJ

    Summary of their solution: SGX

  95. Zash


  96. MattJ

    They are basically storing a database of encryption keys in RAM

  97. MattJ

    So they had to invent Raft-in-SGX so they could replicate across servers and data centres (otherwise all keys would be lost on server failure)

  98. Neustradamus_

    Little question of the day: In MUC Rooms, it is possible to be connected with several XMPP client with the same JID. Example: one with Gajim and one with Conversations So we can see all connected XMPP clients by user like in roster?

  99. Kev


  100. Kev

    Shared nicks in MUCs are hidden, you don't know what's behind them (unlike direct presence).

  101. MattJ

    Maybe :)

  102. MattJ

    Prosody includes an <item> for each joined resource

  103. MattJ

    Not in the spec though

  104. Kev

    Sure, you can expose it.

  105. Ge0rG

    Somebody could update 0045

  106. MattJ

    They did, and it got published as 38 new XEPs

  107. Neustradamus_

    Thanks for your replies :)

  108. Kev

    MattJ: Well, it got published as 1 new XEP and people demanded it be split up...

  109. Neustradamus_

    I would like a clear solution, if it is possible to update it, it will be perfect!

  110. MattJ

    Neustradamus_: it seems to me that there are lots of things you would like. And you expect other people to do them for you immediately and for free

  111. Ge0rG

    MattJ: by "update" I didn't mean "reinvent from basic principles"

  112. Neustradamus_

    No, just specifiy in the XEP... And Prosody already does...

  113. MattJ

    Ge0rG: XEP-0060 is a basic principle? :)

  114. MattJ

    FWIW I actually agree with the split and the pubsub foundations

  115. Ge0rG

    MattJ: yes, didn't you read the longish post by Stephen Wolfram where he derives the working principles of the universe from XEP-0060?

  116. Neustradamus_

    This problem is not new, how many years we can join a MUC Room in several XMPP clients with the same JID?

  117. Ge0rG

    Neustradamus_: there is an article on https://wiki.xmpp.org/web/Multi-Session_Nicks that tracks implementation status

  118. Ge0rG

    feel free to update it with facts.

  119. queen_tilfaar

    Quick question: how many of you will instantly switch to signal if they get rid of phone numbers for login?

  120. Kev


  121. MattJ

    Not I, because I don't believe in centralization and having a communication network relying on a single commercial entity

  122. queen_tilfaar

    Lol zero?

  123. MattJ

    And probably many other people who use/develop XMPP feel similarly

  124. queen_tilfaar

    > Not I, because I don't believe in centralization and having a communication network relying on a single commercial entity Hmm that's understandable

  125. MattJ

    Out of all XMPP users, I'm sure some may switch, sure... 0 might be a stretch. But in this channel right now? 0 may well be accurate

  126. MattJ

    I don't hate Signal, it's a reasonable choice for some people who prefer different trade-offs

  127. queen_tilfaar

    Ikr. The things is its borderline impossible to make my friends and family members switch to open source decentralized complicated solutions urgh

  128. MattJ

    and I appreciate what they are trying to do

  129. MattJ

    But trying to run a centralized service that maintains the privacy of users while providing a good UI/UX is quite hard

  130. queen_tilfaar


  131. MattJ

    They are achieving it using SGX, a magic technology invented for DRM

  132. MattJ

    and multiple flaws have been found in SGX

  133. MattJ

    And it is itself a proprietary technology, and the principle of DRM has been shown to be broken multiple times

  134. MattJ

    It's a really neat hack, and they are inventing fun new stuff this way

  135. MattJ

    But I'm not going to choose it over decentralized alternatives that are based on simpler principles

  136. queen_tilfaar

    Hmm this made me rethink everything

  137. MattJ

    I migrated my family (9 members of) to a new XMPP server the other day, and all it took was an email and one support call

  138. queen_tilfaar

    Haha that's impressive tbh. Meanwhile my brother won't even switch to discord

  139. Ge0rG

    MattJ: you should also say that your new server involved a custom onboarding scheme that's not published as an XEP ;)

  140. MattJ

    It's published openly, and it's not my fault I'm ahead of the curve and the XEP improvements got rejected :)

  141. Ge0rG

    MattJ: technically, it's not XMPP :P

  142. Daniel

    It's still xmpp

  143. MattJ

    I'm not sure how to reach that conclusion

  144. MattJ

    Ge0rG, in any case, your client implements it - so when will you be removing "XMPP" from the description? :)

  145. MattJ

    (and replacing it with "Modern XMPP" of course)

  146. Ge0rG

    MattJ: I thought about "Extended XMPP" or "EX-MPP"

  147. Zash


  148. Ge0rG


  149. MattJ

    We all agreed extensions are bad, right? Just MPP?

  150. Ge0rG

    MattJ: and messaging and presence are only used for spam anyway. Let's reduce to P!

  151. Ge0rG

    it's also featuring a nice pronunciation

  152. Zash

    Is there a XEP for reporting spam/abuse in MUCs?

  153. Zash

    Other than just manually calling for mods

  154. pep.

    Zash, XEP-0224 Attention?

  155. Zash


  156. xnamed^


  157. Ge0rG

    jix.im, is that some kind of yax.im impersonation? :D

  158. Zash

    inb4 yax.in

  159. xnamed^

    Ge0rG: no it has nothing to do with yax.im

  160. edhelas

    Matrix is just a layer on top of XMPP, but you don't know yet

  161. Ge0rG

    this is deep.

  162. edhelas


  163. Ge0rG


  164. Zash


  165. dwd

    I did wonder, idly, whether one could build a connectionless HTTP binding of XMPP, and if so, how much like Matrix it would look.

  166. dwd

    By which I mean, if you pretend that an HTTP-based client is essentially always online, and connections have an enormous timeout, and hand-wave-hand-wave over presence, you'd have an initial client setup phase which looks like Oauth except SASL, and then... what?

  167. Daniel

    matrix is not a real time messaging protocol but a distributed graph database...

  168. Zash

    mod_rest ?

  169. xnamed^

    What's that agenda link in the subject? Access Denied

  170. pep.

    That should be public

  171. pep.

    I can see it here, unauthenticated

  172. pep.

    It's the agenda for board meetings

  173. Daniel

    Works here too

  174. xnamed^

    Then my country blocked

  175. pep.

    can you access trello.com ?

  176. xnamed^

    No, same

  177. pep.


  178. pep.


  179. pep.

    Can I ask which country? Or in private if you prefer

  180. pep.

    Also are you sure that's the only reason

  181. pep.

    Also are you sure that's the only possible reason

  182. xnamed^

    Ok, sent in private

  183. pep.

    Trello's support things seem useless

  184. pep.

    If you can provide more info that allow us to ensure it's indeed your IP/country that's being blocked, I'll open a ticket on their community forum.

  185. pep.

    And if nothing changes (which I'm almost certain), I'll raise that to board

  186. xnamed^

    I think there is nothing we can do, it's US ban

  187. pep.

    Can you dig trello.com?

  188. xnamed^

    I live in Latakia Syria, regime controlled, I don't know what more information to tell

  189. pep.

    They also have servers in europe apparently. That's what their dns give me from here, and from Asia they give me the US servers

  190. mathieui

    https://pix.mathieui.net/o/UobYh.png well if you need the agenda, xnamed^

  191. xnamed^

    is there any XEP for keyboards like in Telegram bots ( https://core.telegram.org/bots#keyboards )?

  192. pep.

    I guess this might help? https://xmpp.org/extensions/xep-0439.html

  193. xnamed^

    thanks pep.

  194. SamWhited

    Hi all; IIRC MattJ is working on an update to MAM so hopefully that will be undeferred soon, but XEP-0359 is also deferred and it's required by MAM and generally being used more and more. Can we undeferr it somehow? Maybe just by issuing a LC, or is anyone planning changes to it soon?

  195. SamWhited

    I was thinking about using it in something, but it's just confusing to everyone when more and more of the ecosystem is using specs that say that you shouldn't use them in big red letters at the top, so it would be nice if we could change this.

  196. MattJ

    I have two concerns about it right now: I (like a number of other people) strongly feel that origin-id should be removed, or a rule added that it must always match the id attribute if present

  197. MattJ

    Secondly it was meant to decouple ids from MAM, but it hasn't in practice

  198. MattJ

    There is no way to add an id to a stanza without archiving it if you are an archiving entity

  199. SamWhited

    Yah, I'm not a huge fan of it either, I just hate us relying on something that's deferred everywhere. MAM is a huge part of the ecosystem already, and you wouldn't know it if you find it by searching for "how to have archives in XMPP" or something.

  200. pep.

    I say remove Deferred? :x

  201. pep.

    This state is just useless

  202. pep.

    There the last modified date at the top, it's enough already

  203. SamWhited

    I disagree with removing deferred, it's very useful in general, I just think we should be careful that widely implemented and popular parts of the ecosystem actually get moved forward.

  204. SamWhited

    Or even if that just means having a whitelist where council decides "this is popular, it should not go to deferred even if it hasn't been modified in a while"

  205. pep.

    How is it useful?

  206. pep.

    What's the goal of deferred really

  207. pep.

    If it's only "indicating that something hasn't been updated in a while", then there's a date at the top already.

  208. SamWhited

    So that I'm not tempted to implement every random crappy XEP that someone submitted once and no one implemented but now it's in the list

  209. pep.

    And then that confuses everybody who doesn't understand our process

  210. SamWhited

    No one looks at dates.

  211. SamWhited

    They just scroll down the list of XEPs on the /extensions page of the website, or stumble upon them from a search.

  212. SamWhited

    We want to keep that list at least sort of manageable

  213. pep.

    Why would there be a whitelist of XEPs that shouldn't go in deferred. Isn't deferred supposed to indicate that a XEP hasn't been updated in a while?

  214. SamWhited

    Because some XEPs haven't been updated in a while but are also widely used and popular.

  215. SamWhited

    And those should still be in the list and we still want to encourage experimental implementations of them.

  216. pep.

    Sure, Deferred doesn't prevent a XEP from being used

  217. SamWhited

    I never said that it did

  218. pep.

    And it's still equivalent to Experimental

  219. pep.

    Not sure what's the issue

  220. pep.

    If you're going to make exceptions I say just remove it. (I say remove it anyway..)

  221. SamWhited

    The difference is that experimental says this at the top: "the protocol described herein is encouraged in exploratory implementations"

  222. SamWhited

    And deferred says this: "Implementation of the protocol described herein is not recommended for production systems"

  223. SamWhited

    We want to eventually reach that last state where we say "no one has looked at this in a while and it never took off, so probably don't do it" and council won't vote on every one, so automatic deferral is probably good.

  224. SamWhited

    However, council also doesn't move things forward very fast, so the way we have it setup right now it catches too many false positives and defers useful things.

  225. SamWhited

    So I'm just spitballing suggestions for how we could fix that.

  226. pep.

    I also proposed one

  227. SamWhited

    I know, and I tried to explain why I thought it was a bad idea.

  228. pep.

    Well all I hear you saying is "I don't like that it's not stated on deferred XEPs that it's still equivalent to experimental"

  229. SamWhited

    You'll end up having some sort of deferred state anyways, council will just have to decide when to move things to it and will forget and won't move tons of random old crap which will stay in experimental forever.

  230. pep.

    That's an easy fix

  231. SamWhited

    It's not still equivalent to experimental, I literally just posted why they're different.

  232. pep.

    It's experimental + time passed

  233. SamWhited

    No, it's not. It's "don't implement this" and experimental is "try implementing this and tell us what happens"

  234. SamWhited

    If you remove the time limit, then council ends up having to move to some deferred like state anyways because we want a way to say "don't implement this"

  235. pep.

    Why would time be the only factor in choosing to implement a spec, that's.. weird

  236. pep.

    (not to say stupid)

  237. pep.

    Council is not the only factor here

  238. SamWhited

    It doesn't have to be, that's exactly what I'm saying, we should find an alternative. Having time as one of those factors just takes weight off of councils shoulders though because they don't have to remember to double check every random experimental XEP to see if they should defer it every year or so

  239. pep.

    Message retraction was a good example for this

  240. pep.

    Somebody sent it, it got LC'd iirc, it got dropped by the author, then 3-4 years later somebody digged it up

  241. pep.

    (LC'd and refused)

  242. pep.

    Tbh I don't like our process very much. Experimental or not, XEPs are gonna change anyway, or they're gonna be changed by other XEPs (which is exactly the same to me). As a developer, Deferred doesn't give me any concrete information apart from "Somebody (possibly multiple) didn't have time to look into it".

  243. pep.

    I'd rather have rejection reasons included in specs when they've gone through LC already

  244. pep.

    rather than just leaving it in a big bag of who-knows-whats-gonna-happen-to-these

  245. SamWhited

    Oh yah, I definitely think it would be beneficial to have a rejection summary in the specs, that would be great. For everything else though, deferred is useful because it's important to know "Somebody didn't have time to look into it"

  246. pep.

    How is that important. Somebody did make the effort to come up with the idea at least

  247. pep.

    How is that important. Somebody did make the effort to write down their idea at least

  248. SamWhited

    They did, and that doesn't mean the XSF should encourage implementing it. We have enough confusion without a million old XEPs that someone touched once and then never looked at again floating around with banners at the top saying "Try implementing me and see what happens"

  249. SamWhited

    If no one has touched it in a while and it never got popular, it makes sense to step back and not encourage it unless someone wants to pick up the slack and work on it again.

  250. pep.

    "that doesn't mean the XSF should encourage implementing it", the XSF already does. For a year after it's been promoted to Experimental

  251. pep.

    What has changed is.. time

  252. SamWhited

    I know, that's literally what I'm saying.

  253. xnamed^

    > I guess this might help? https://xmpp.org/extensions/xep-0439.html Great, what about suggestions too while typing a command, maybe we can add option to request bot commands : Prefix Description Syntax, to be used by the client, for example autocomplete nicknames and JIDs, and to send command correctly Maybe some icons

  254. pep.

    SamWhited, Yeah and then you get things like MAM as you said earlier. My feeling about a whitelist is "meh", sorry I don't have much feedback, but having an exception to the process feels weird

  255. SamWhited

    yah, fair enough, a whitelist would feel weird to me too

  256. SamWhited

    Maybe some other state between experimental and draft, or just redefine draft to be easier to edit.

  257. pep.

    We should try to kill this myths that nothing changes :)

  258. SamWhited

    MAM doesn't seem to fit into deferred at all, and is currently not ready for the current draft state (apparently since it's still being modified a lot and doesn't survive last calls), but it's obviously widely adopted and the ecosystem doesn't really work without it, so it seems like there should be something else for it.

  259. pep.

    "a lot" is quite relative

  260. pep.

    It changes.

  261. SamWhited

    Fine, it changes. Doesn't really matter if it's "a lot" or once every few years, the point still stands.

  262. pep.

    I'm no council but I could see it in draft tbh

  263. SamWhited

    Oh yah, personally on this particular spec I think we should just move it to draft and be done with it, but I feel the same way for carbons and a lot of other stuff

  264. pep.


  265. SamWhited

    So if it doesn't fit in experimental (which council may or may not agree with, I dunno) and council doesn't think it fits in draft, I can only conclude that something needs to change.

  266. pep.

    Then when somebody(tm) figures out how to fix carbon, either fix the document, or if too many people complain then make a new one (it's the same anyway..)

  267. pep.

    xnamed^, that would depend on the client

  268. pep.

    When sending the message, the bot would state what commands it expects

  269. pep.

    The client can use this information

  270. pep.

    SamWhited, maybe that means the XSF needs to put more effort in getting these things adopted :)

  271. SamWhited

    pep. agreed.

  272. SamWhited

    The editors have been doing a good job of at least LCing stuff recently, which is great.

  273. pep.

    We can't force implementations to update their codebase instantly though, for feedback

  274. pep.

    We can sponsors things to be implemented, certainly

  275. SamWhited

    Anyways, I'm going back offline now, if an editor could move XEP-0359 out of deferred, however that's done, I'd appreciate it. A LC might be good on that one just to solicit more feedback and get it back to experimental.

  276. xnamed^

    pep.: I think depending on both, what client would expect from bot as normal message and use that information for command suggestions, the idea is to reduce typing and sending messages

  277. pep.

    I'm not sure what more you need from the bot

  278. xnamed^

    First thing need to tell the client this is a bot 😁

  279. pep.

    You don't actually need to know it's a bot do you

  280. pep.

    You just need to see there are preformatted answers you can use

  281. pep.

    But anyway, if you really want to know it's a bot, you can check XEP-0030 identities, https://xmpp.org/registrar/disco-categories.html#client

  282. xnamed^

    Not exactly I need to know if bot or not, but if has commands which can be used for suggestions

  283. xnamed^

    Same way of ad hoc commands

  284. pep.

    Then you can use the 0439 as I linked earlier

  285. pep.

    If you see such payload then you know what to reply

  286. pep.

    If you receive such payload then you know what to reply

  287. pep.

    xnamed^, https://core.telegram.org/bots#commands < for something like this, use ad-hoc? And then maybe find/write a way to advertize this is the set of commands you support as a bot

  288. pep.

    Not sure if there's such a thing already

  289. pep.

    It might be weird though to use ad-hoc and also send messages

  290. xnamed^

    Yes, so I suggest to be new xep