XSF Discussion - 2017-03-20


  1. jonasw

    I’m not an XML Schema guru, but we’re currently looking at the schema for XEP-0084. It appears to me that it doesn’t allow any attributes for <pointer/>, but in the text it is specified that pointer MAY have some attributes (those already specified for <info/>).

  2. dwd

    jonasw, Our schemas are often rubbish, yes. In the case of the <pointer/>, I take it you're interested in implementing this? I don't *think* anyone else has.

  3. jonasw

    not really

  4. jonasw

    just a stub

  5. jonasw

    well, we’re implementing XEP-84, but not <pointer/>, to make it clear

  6. dwd

    I'd be inclined to strip <pointer/>, even if it's Draft, to be honest. I can't see how it's interoperable.

  7. jonasw

    I find it a bit annoying that one can only save image/png in PEP there

  8. jonasw

    I understand and welcome that image/png is required, but from my reading the XEP explicitly forbids anything but image/png in the :data node :(

  9. Zash

    Only when only one node is supported, like how some popular implementation(s?) do it.

  10. jonasw

    what do you mean?

  11. dwd

    Zash, No, I think the text as written restricts the <data/> element to be image/png only.

  12. Zash

    What

  13. jonasw

    yes

  14. Zash

    Where?

  15. dwd

    Zash, §4.1

  16. Zash

    -xep 84

  17. jonasw

    > The XML character data MUST represent the image data for the avatar with a content-type of "image/png", Base64-encoded in accordance with Section 4 of RFC 4648 [10]. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)

  18. Bunneh

    Zash: XEP-0084: User Avatar (Standards Track, Draft, 2016-07-09) See: https://xmpp.org/extensions/xep-0084.html

  19. Zash

    Is that new?

  20. jonasw

    hopefully not. this is a MUST and the XEP has been in draft since 2008 or something :)

  21. jonasw

    2007 even

  22. dwd

    Changed in 2007, just before Last Call.

  23. dwd

    Version 0.12. Or at least, that's when the line was edited.

  24. Zash

    I thought that it said "If only one item is published, it has to be PNG. Other items can be whatever."

  25. dwd

    Oh, mind you, "The XML character data MUST represent the image data for the avatar with a content-type of "image/png"", edited in 2007-02-23, which doesn't appear in the version history.

  26. Zash

    But since in practice you are going to have a hard time publishing multiple items...

  27. Zash

    The png-only text shows up in https://xmpp.org/extensions/attic/jep-0084-0.7.html#proto

  28. jonasw

    wait, if PEP won’t allow more than one item the XEP has a data race

  29. Zash

    Wasn't there a feature for that?

  30. jonasw

    dwd: let’s keep <pointer/>

  31. jonasw

    it may be useful if we ever want to extend XEP-84.

  32. jonasw

    saves a replacement.

  33. Tobias

    fippo, what's google meet? their new duo?

  34. Zash

    Yet another Google messenger?

  35. Tobias

    https://meet.google.com/

  36. Tobias

    maybe a gotomeeting like thing from google?

  37. Tobias

    https://techcrunch.com/2017/02/28/google-quietly-launches-meet-an-enterprise-friendly-version-of-hangouts/

  38. nyco

    yes, more or less

  39. nyco

    whereas the other is more like a Slack/HipChat

  40. Tobias

    they got an alternative to Slack/hipchat?

  41. Ge0rG

    Hey, while we are talking about Slack. If you slack a message to yourself, it's just stored on the server and reflected to your other devices. In XMPP (with Carbons), every one of your devices has two copies in the end

  42. Ge0rG

    Would it be sensible to change Core routing / Carbons to only deliver the message to your _other_ clients?

  43. Ge0rG

    or is this something that should be handled in the client?

  44. nyco

    Ge0rG, marginal case, as I guess? or is there real use?

  45. Tobias

    Ge0rG, MAM should be the source of truth, not?

  46. Ge0rG

    nyco: I'm messaging myself all the time (URLs to my mobile etc), and I'm using a secondary JID because duplicates look bad

  47. Ge0rG

    Tobias: MAM will obviously also contain two copies

  48. Ge0rG

    Tobias: the incoming and the outgoing one

  49. Tobias

    Ge0rG, yeah?

  50. nyco

    so why not store those things in a private pubsub node?

  51. Tobias

    Ge0rG, maybe there could be a mention of it in MAM to allow server to optionally remove that one duplicate

  52. Ge0rG

    nyco: because every client supports messaging, and no clients support private pubsub nodes.

  53. Ge0rG

    Tobias: that's not so easy.

  54. Ge0rG

    Tobias: MAM is only if you come online later on. Carbons / core 6121 is when you are online

  55. Ge0rG

    Which is one of the reasons I'm insisting on making MAM-subscribe a thing.

  56. intosi

    Ge0rG: that's what M-Link does. Messages to self are archived just once.

  57. intosi

    And, as a result, returned just once.

  58. Ge0rG

    intosi: are carbons of messages-to-self also inhibited?

  59. intosi

    Carbons are not archived.

  60. Ge0rG

    intosi: if I'm online with /A and /B, and I send a message from /A to bare-JID (or even to /A), which client will receive how many copies again?

  61. intosi

    And messages to self follow the normal carbons rules. Only interested clients that aren't snders or recipients already will receive them,

  62. Ge0rG

    intosi: because a message-to-self is two messages in most cases :>

  63. Ge0rG

    and from my reading of 6121+Carbons, you can't strip out one of them without violating the protocol

  64. intosi

    I'll probably regret asking immediately, but why?

  65. Ge0rG

    intosi: an incoming message must be delivered to a subset of the available resources by 6121, and to all other resources that have carbons by 0280

  66. Ge0rG

    intosi: and an outgoing message must be carboned to all other carbon-enabled resources

  67. intosi

    Yeah, sure. And you're claiming a server must do both sent and received handling separate?

  68. Ge0rG

    from a technical PoV, a message to self is first an outgoing message from your sending client, and then an incoming message to wherever it was addressed

  69. intosi

    I chose not to do that, it's stupid.

  70. Ge0rG

    intosi: actually I'll gladly accept a different reading of the RFC, but it seems like you were the only one to do the "right" thing, and I'd be surprised if it's backed by the RFC

  71. fippo

    tobias: video hangouts with a new interface. watch https://www.youtube.com/watch?v=8a-mmT9ifss if you're interested

  72. Tobias

    fippo, ta

  73. intosi

    It followed from my reading of 280, interpreting it as a hint on which resources should receive the message. It makes no sense at all to handle the sent and received carbons separately when from and to are the same account.

  74. intosi

    On which resources, apart from normal RFC routing, I mean.

  75. Ge0rG

    intosi: you are right of course. But even normal RFC routing is convoluted in this case.

  76. intosi

    Didn't touch RFC routing rules at all.

  77. Ge0rG

    intosi: if you don't touch RFC routing, you'll end up in an even weirder place. Imagine that RFC routing rules require you to send the message back to the sending client.

  78. Ge0rG

    Then the sending client will end up with two copied, and every other client with only 1.

  79. intosi

    Ge0rG: perhaps in your code base.

  80. Ge0rG

    intosi: no, RFC 6121 is very clear on this. https://tools.ietf.org/html/rfc6121#section-8.5.2 and https://tools.ietf.org/html/rfc6121#section-8.5.3

  81. Ge0rG

    there is no "you can ignore the sending JID of self-messages" exception

  82. Ge0rG

    I wish there were.

  83. intosi

    I'm probably too stupid to understand what your problem is.

  84. Flow

    Ge0rG: So you are saying we can't add a sentence to 280 that carbons of self-messages should not be send to the sending resource?

  85. Ge0rG

    intosi: I want to ask my favorite server's developers to reduce the number of self-messages from 2 to 1, but RFC6121 disallows that.

  86. Ge0rG

    Flow: no. I'm saying that, carbons-aside, you'll end up with partial message duplication based on 6121.

  87. Ge0rG

    Flow: this can't be fixed in carbons only. And if we try, we'll end up with {1..2} messages arriving at different clients

  88. Flow

    Hmm, I think I don't have the whole picture of the problem. Maybe post to standards@?

  89. Ge0rG

    But then again, I also think that 6121 bare-JID routing rules are fundamentally broken for the IM use case.

  90. Ge0rG

    Flow, lovetox, intosi: https://mail.jabber.org/pipermail/standards/2017-March/032421.html

  91. intosi

    Ah, now I understand you. Yes, foo/A sending to foo will result in a copy to self.

  92. intosi

    See, I'm too stupid to understand your words.

  93. Ge0rG

    intosi: I'm too stupid to find the right words to make the problem accessible

  94. intosi

    What will not happen, is sent carbons to be generated, even if you send to a bound JID foo/B.

  95. Ge0rG

    intosi: feel free to comment that you won't violate 6121, and that my claim of such is a blatant lie

  96. intosi

    Like I said, I didn't touch core routing rules for carbons. Not delivering the message to self when insisting on an unbound bare self jid would violate the RFC.

  97. intosi

    Anyway, sensible clients bind to a full jid as soon as they can anyway.

  98. Ge0rG

    intosi: resource-binding only adds to the uncertainity

  99. Ge0rG

    sensible clients should always send to bareJID because the server knows better which resources are there.

  100. Ge0rG

    the only exception is OTR, which is considered generally broken.

  101. intosi

    I disagree, except for the OTR bit.

  102. dwd

    Ge0rG, "always"?

  103. Ge0rG

    dwd: yeah.

  104. dwd

    https://xmpp.org/extensions/xep-0296.html

  105. Ge0rG

    dwd: following that XEP leads right into madness land.

  106. Holger

    It would be so nice if that idea worked out in practice ...

  107. Ge0rG

    dwd: just consider the race conditions between sending a message to a locked JID and that locked JID disappearing.

  108. Ge0rG

    Things are getting even funnier if you change client behavior based on the locked JID's supported features.

  109. Ge0rG

    You start typing a LMC correction, but then another client of your buddy comes online, you get unlocked and your client refuses to LMC.

  110. Ge0rG

    ..or doesn't ask for a 0184 ack.

  111. Ge0rG

    And I don't even want to get started about different message routing rules, which cause a "real" message vs. a carbon to arrive at your destination.

  112. dwd

    You seem to have got started on the thing you claim you don't want to get started on.

  113. Ge0rG

    Seriously, we need to reconsider all that and just say that unless explicitly required, all messages should go to bare-JID, because we want to talk to the "account" and not to the "client".

  114. Ge0rG

    dwd: no, I didn't. Carbons are a whole different can of worms.

  115. Flow

    Ge0rG: I believe any sensible client does already that

  116. Ge0rG

    Flow: does what?

  117. Ge0rG

    Flow: intosi> Anyway, sensible clients bind to a full jid as soon as they can anyway.

  118. Flow

    Ge0rG: But with carbons on both ends, where is the issue when performing resource locking?

  119. Ge0rG

    Flow: see above.

  120. Ge0rG

    Flow: also, if the receiving client goes offline, even with carbons, the server will generate error responses for the queued messages

  121. Flow

    fair point, but you don't have to convince me. If I where to write an XMPP IM client I would probably always send messages to bare JIDs

  122. Ge0rG is an ignorant developer as well. Just doesn't care about CAPS and sends whatever features he wants to the bare JID

  123. Ge0rG

    because most of the features supported by yaxim fail safe, and because it doesn't support many features, it works out excellently.

  124. Flow

    CAPS?

  125. Ge0rG

    Flow: 0030/0115

  126. lovetox

    so is there any use case for https://xmpp.org/extensions/xep-0201.html except the ones described in the xep, because i dont really feel i dont need the ones described in the xep

  127. jonasw

    lovetox: actually, those use cases are awesome. the problem is only that noone has ever found a good UI for them.

  128. lovetox

    they feel like "look what we could do if somebody would find some use case for this"

  129. Ge0rG

    I'd love to be able to collapse threads I'm not interested in. But that would require XMPP clients to actively mark messages with the correct thread-id

  130. jonasw

    +1 Ge0rG

  131. jonasw

    haven’t had a good idea yet, unfortunately

  132. Ge0rG

    I'm actually thinking about adding a thread-ID in yaxim when you tap on a nickname to do nickname completion

  133. jonasw

    not sure that’d perform well

  134. Ge0rG

    jonasw: it would probably cause gazillions of false-positives, but then again: no sane client relies on thread-ids to mean anything :P

  135. lovetox

    you mean in a muc

  136. Ge0rG

    lovetox: yeah

  137. lovetox

    so that you tap a button and start a new thread

  138. lovetox

    and how does the other client respond to the thread?

  139. jonasw

    with tapping I can actually imagine that this would work

  140. Ge0rG

    lovetox: no. you tap on a message to continue that thread

  141. jonasw

    I cannot imagine how that works in a desktop application

  142. jonasw

    as soon as you have multiple threads with overlapping participants :(

  143. Ge0rG

    jonasw: also tab completion :P

  144. jonasw

    Ge0rG: see above

  145. jonasw

    with yaxim you could use the thread of the message which the user tapped at for completion

  146. lovetox

    and then reorder messages so messages from threads are grouped?

  147. jonasw

    maybe

  148. Ge0rG

    maybe one could add colors to message threads

  149. Ge0rG

    as a subtle hint

  150. jonasw

    like this? https://wiki.xmpp.org/web/Contact_Colors

  151. Ge0rG

    anyway, I gotta run.

  152. Ge0rG

    jonasw: yeah, nickname --> text color; thread --> bg color

  153. Ge0rG

    severe eye injury!

  154. jonasw

    ouch

  155. lovetox

    so for muc i feel this is not too hard to implement

  156. lovetox

    its just the ui how you respnd

  157. lovetox

    or switch thread

  158. jonasw

    yes, the UI is hard

  159. jonasw

    exactly

  160. jonasw

    unfortunately; because I think it could add a lot of it worked magically

  161. Ge0rG

    that would intuitively work for pseudo-forums, but not for IM

  162. jonasw

    wtf

  163. lovetox

    there needs to be a feature, that lets me add a name to the thread

  164. jonasw

    the wiki dropped my non-latin1-characters

  165. jonasw

    what the heck

  166. lovetox

    so then someone could hit a key and cycle the thread names

  167. lovetox

    and write to the one he wants

  168. Ge0rG

    lovetox: why names? just use <Tab> to color-highlight the threads one by one.

  169. lovetox

    can we just add a name tag to the thread element

  170. Ge0rG

    Or maybe... Meta-Tab, because Tab is already used for nick completion :P

  171. lovetox

    on desktop i have endless possibilities with shortcuts i dont see a problem with that

  172. Ge0rG

    lovetox: yes, but your users don't have infinite memory for shortcuts

  173. jonasw

    right

  174. lovetox

    so the client automatically gives a color to a new thread

  175. jonasw

    this is IM, not blender

  176. lovetox

    this can get tricky in a muc with much threads

  177. lovetox

    names are better i think

  178. jonasw

    names requires extra user interaction

  179. jonasw

    -> won’t be used

  180. Ge0rG

    lovetox: MS Teams has multiple input boxes per thread level. The one in the bottom starts new threads, and then there is a box in each thread at each level, to allow answering there

  181. jonasw

    hm, interesting approach, too

  182. lovetox

    but to be honest, on a smartphone, a muc is cramped already

  183. lovetox

    on desktop this could be a really nice feature

  184. lovetox

    i mean you have space for 3 messages on a smartphone ^^

  185. Ge0rG

    I have enough space for five

  186. lovetox

    threads or not, you will not have a sense of overview in a muc on a smartphone

  187. lovetox

    especially not one where much goes on

  188. jonasw

    depends, if the threads are properly done and you view only those you are interested in…

  189. jonasw

    but I doubt that will work reliably, because users will accidentally post messages in the wrong thread

  190. jonasw

    interesting question: can LMC modify the <thread/>?

  191. Ge0rG

    yeah, collapsing / ignoring threads would be awesome on smartphones

  192. Ge0rG

    "The Sender MUST NOT include a correction for a message with non-messaging payloads." - looks to me like it's not forbidden

  193. Ge0rG &

  194. jonasw

    fg

  195. Ge0rG

    What? Hey!

  196. lovetox

    yeah pretty nice idea for threads

  197. lovetox

    but i see this more as a feature for serious work groups etc

  198. lovetox

    not for your everyday muc

  199. jonasw

    lovetox, indeed

  200. lovetox

    on desktop you could capture all threads put them into a list

  201. lovetox

    let the user name them

  202. Ge0rG

    If done right, it could work for both

  203. lovetox

    on click open a tab that displays only msgs from that thread

  204. lovetox

    that way i also know to which thread a user wants to respond

  205. Ge0rG

    But then, there will be the one client that fails, the Outlook of XMPP, the Pidgin of Carbons, where it's just plain broken

  206. lovetox

    i just treat it like a new conversation

  207. lovetox

    yeah Ge0rG thats why i said its probably only for serious groups

  208. lovetox

    that know what they are doing

  209. Ge0rG

    lovetox: rule number 1 of interface design: users don't know what they are doing

  210. jonasw

    that

  211. lovetox

    Ge0rG, on the topic of self messaging

  212. lovetox

    receipts have no use in my opinion

  213. lovetox

    on sent message if you dont get a error stanza from the server, you can see it as delivered

  214. lovetox

    it doesnt matter if your other client is online and sends a received stanza..

  215. jonasw

    right, stream management tells you that it has been processed by the server

  216. lovetox

    i dont know when i ever would need that info

  217. lovetox

    i mean if you client is not totally broken you will get that message via MAM or offline message or carbons or whatever

  218. jonasw

    you’d want to be sure that you can find it in MAM later

  219. jonasw

    for this you need to make sure that the message actually makes it to the server

  220. jonasw

    -> SM

  221. Ge0rG

    lovetox: see, some client developers can't even send a coherent message with a highlight, how are Normal Users supposed to manage threads? 😀

  222. lovetox

    so i think i will deactivate receipts for self messaging, its only noise

  223. Ge0rG

    lovetox: sounds good enough to me.

  224. lovetox

    chatstates dito

  225. Ge0rG

    Yeah, ideally 0198 will manage the thing. However, I'd still like to show green checkmarks, just maybe with a different logic to create them.

  226. jonasw

    Ge0rG: SM should be a sufficient source for that, no?

  227. lovetox

    yeah though, in most cases i dont have events for sm stanzas in my application, and its maybe not so easy to link them to messages, for example my first idea would also be just to use the "sent" carbon that i get as a receipt

  228. lovetox

    at least in gajim that would be way easier then to do this via sm stanzas

  229. Ge0rG

    lovetox: no 'sent' receipt on outgoing message

  230. Tobias

    fippo, regarding that video..."you want ford be able to call general motors, etc." that all sounds like a nice fit for a federated system, but then again it's google

  231. lovetox

    Ge0rG, then the received ?

  232. lovetox

    that we want to get rid off ^^

  233. Ge0rG

    lovetox: Yeah, unless you're on mlink

  234. fippo

    tobias: well, meet. doesn't work in Firefox anymore than hangouts does...

  235. lovetox

    see now would be cool when we could join our own thread Ge0rG :D

  236. Tobias

    hangouts requires a plugin in FF anyway, not?

  237. fippo

    well, npapi died.

  238. Ge0rG

    lovetox: Yeah. Good luck getting that UX sorted out and introduced into all Jabber.. No, XMPP clients.

  239. lovetox

    maybe i do it once just for fun, i think gajim has already everything set up for it, window manager, thread managing, it just needs to be connected and a little bit of UI :)

  240. jonasw

    i doubt that it is "a little bit of UI", but sure. make a nice demo, I’d be interested in how this can work nicely

  241. lovetox

    i described it above, i would gather the different threads and display them in a list

  242. lovetox

    when the user clicks that list, a window opens where the messages are filtered with the thread

  243. Ge0rG

    This might also not be the biggest problem that gajim has...

  244. lovetox

    if he writes into that window, message goes to the thread

  245. lovetox

    seems pretty easy

  246. lovetox

    on desktop i dont have to put everything into one window :)

  247. jonasw

    yes you have.

  248. jonasw

    (but that is just my humble opinion ;-))

  249. lovetox

    dont limit the desktop to a bigger smartphone :)

  250. jonasw

    don’t litter my desktop with windows

  251. lovetox

    i actually dont, i can also use tabs inside one window ^^

  252. SamWhited

    What happens if I'm in a client that doesn't support threading and I reply to the discussion, then other people reply to me? It probably doesn't show up in your tab, and then you only see half the discussion and the thread is broken.

  253. lovetox

    yeah SamWhited of course you can sabotage it .. but if only gajim clients talk with each other it would work good :)

  254. lovetox

    and maybe others adopt it

  255. lovetox

    :)

  256. jonasw

    that’s not sabotaging, that’s simply interoperating

  257. SamWhited

    I read that as "so it will never work"

  258. jonasw

    or rather not interoperating

  259. SamWhited

    I'd love to see the UX issues around threading worked out; I've thought about this a lot and never been able to come up with a good way to do it that didn't just break constantly.

  260. lovetox

    but the breaking has nothing to do with your UX

  261. lovetox

    it has to do with other clients

  262. Ge0rG

    You just add a context menu "join with thread" that opens a sub menu with a list of all threads

  263. jonasw

    SamWhited: however, in lovetox’ defense: you will never be able to interoperate with clients which do not do threading properly. that’s simply how it is, it’s the same for email.

  264. SamWhited

    It doesn't matter; there will be other clients in the chat, and if they break the threading on my end and I'm a user all I know is "threading is broken, this is bad"

  265. jonasw

    indeed

  266. lovetox

    somebody has to start

  267. jonasw

    yes, it’s tricky

  268. jonasw

    it would be good if one could somehow sanely detect these clients and fall back to a sane non-threaded UI for those

  269. jonasw

    or rather if those clients participate

  270. Ge0rG

    Or you'll end up with implausible requirements similar to OMEMO/MUC. All of the participants need to implement "Easy XMPP" and you need to have them in your roster for threading to work.

  271. SamWhited

    Now you have a UI inconsistency between rooms that have some other client joined, and rooms that don't, which also feels poor (maybe better, maybe worse? I'm not sure)

  272. lovetox

    as i said i would just show a list with all threads, you dont have to click them and join, you can just watch the muc like now ..

  273. lovetox

    its just a addtional tab when you want to use it and it works

  274. jonasw

    SamWhited: I think it’s better, because it is a more or less sane upgrade path to a world where all clients can do that

  275. SamWhited

    Also between the same room on one day and the same room 10 minutes later

  276. jonasw

    ugh

  277. jonasw

    it’s all a mess.

  278. SamWhited

    When I'm in a room, and a client that doesn't support threading joins, do all my threads just close? That will feel poor

  279. jonasw

    on a related matter: a XEP which allows me to post a simple reaction to a post would be great

  280. jonasw

    I’ve seen that with slack I think. or like you can on github issues

  281. jonasw

    those wouldn’t trigger any UI notifications, and it saves vertical space

  282. Lance

    https://xmpp.org/extensions/xep-0367.html ?

  283. lovetox

    SamWhited, why would a thread close? the messages have that thread on them and i can filter the window for it, it doesnt matter what another client does, except spamming my thread maybe

  284. SamWhited

    Yah, that's one of the things we were going to use 0367 for, although it's not called out explicitly and I don't think it's happening now

  285. jonasw

    SamWhited: do it like youtube "User XY does not have threading, thus we have to fold it all. We are sorry. (Blame them and hunt them with pitchforks & torches)"

  286. jonasw

    ah cool, SamWhited

  287. jonasw

    I was already thinking about 367, but it seemed to be too broad for that. if it is intended to serve that purpose, great!

  288. SamWhited

    lovetox: But now when that user replies, your threads break and we're back to the beginning

  289. Ge0rG

    Somehow, my smartphone miscompleted roster into rosette...

  290. lovetox

    why would it break? what does breaking mean for you?

  291. lovetox

    adding a message that doesnt belong to the thread is breaking?

  292. jonasw

    lovetox: not correctly showing semantically related messages all the time

  293. jonasw

    yes.

  294. jonasw

    that’s breaking.

  295. SamWhited

    Their messages don't show up in the thread, and people are replying to the conversation both in the threaded room and in the non-threaded room

  296. Lance

    SamWhited: it'd also need message retracted to do the full reaction UX, but yeah that's what I had plans for with 367 too

  297. SamWhited

    now the thread is split between two places

  298. lovetox

    so when i go to a message board and post in the wrong topic, i broke the topic?

  299. SamWhited

    Lance: ah yah, good point; we never actually got that far

  300. lovetox

    yeah that people answer to it with the wrong thread on the message, ok

  301. lovetox

    that is a problem in the start

  302. lovetox

    that the filtering is not good

  303. lovetox

    but it would get better and better as more clients adapt

  304. lovetox

    this does not even mean implementing the same thing

  305. lovetox

    just use some sane rules on threads

  306. SamWhited

    It's nto that people are posting to the wrong topic though; a message board will show everyone a consistent view of what the topics are. It's juts that users are posting the only way they can, and it's breaking the thread for some users but not others.

  307. Ge0rG

    lovetox: in 20 years, there will still be people on the xsf MIX using Pidgin.

  308. lovetox

    i bet i get Ge0rG and inputmice, Link Mauve , mathieui and probably one or two other devs to not break my shiny new thread feature

  309. lovetox

    and we ban the rest from all mucs :D

  310. Ge0rG

    lovetox: on mobile, people will just tap on the first instance of the person they want to complete.

  311. Ge0rG

    And you really really really don't want to promote lightweight threads to windows

  312. SamWhited

    I tried a web chat thing recently that did threads as windows; I thought it worked pretty well, the only problem was that it also kept the threads in the main chat view, which meant everyone just replied in the main chat view and the threads never got used

  313. Ge0rG

    SamWhited: sounds like slack

  314. lovetox

    UI for naming the threads then use tab completion

  315. SamWhited

    I haven't actually tried Slack since they introduced threading

  316. SamWhited

    lovetox: It's still more work than just typing your message and hitting enter, which means most people will ignore it

  317. Ge0rG

    SamWhited: I was the only one to try threading, so I consider it a UX failure

  318. lovetox

    not everything has to be used by everyone

  319. SamWhited

    Ge0rG: Yah, that's how I was with this messenger (I forget what it's called) that our team was playing with

  320. SamWhited

    lovetox: it does in this case, otherwise the threading is always broken and worthless

  321. SamWhited

    everyone or at least most people

  322. Ge0rG

    lovetox: you would need to provide visual hints, like color codes for the U to work out

  323. SamWhited

    That's what this did, which was actually rather nice, let me ask what it was called…

  324. lovetox

    ok what about this

  325. lovetox

    a work feature: there is no main chat view

  326. lovetox

    only a add thread button

  327. lovetox

    every thread gets his own window

  328. lovetox

    you can only answer to threads

  329. SamWhited

    Isn't taht just making new mucs at that point? (also, that still requires every client to do it)

  330. lovetox

    when you join you load mam, and get automatically a list with all threads

  331. Ge0rG

    lovetox: Yeah, will be broken immediately by an incompatible client

  332. lovetox

    thats why i said its a work feature

  333. lovetox

    like a company if they all use the same client

  334. Ge0rG

    And then some client will use auto increment integers for threads ids

  335. lovetox

    making a new muc has considerable overhead

  336. SamWhited

    yah, fair enough, it can work in closed environments

  337. lovetox

    actually is that not exactly what we need for mailing list replacement ^^

  338. lovetox

    a search function added and its perfect

  339. lovetox

    and its all archived in one single muc :D

  340. Ge0rG

    "Sending of MUC messages without a thread ID is disallowed by group policy. Please contact your chat administrator."

  341. Ge0rG

    lovetox: and you only can get the last 50 messages.

  342. SamWhited

    CA Flowdock is the thing we were looking at that did threading, btw; might be worth experimenting with if you're trying to do this: https://www.flowdock.com/

  343. SamWhited

    It was pretty nice looking, but when we tried it no one used threads, so I felt like it was a failure.

  344. SamWhited

    Or rather, one person did, and everyone else replied in the normal chat and then they didn't see replies in the thread

  345. Ge0rG

    SamWhited: maybe they were using the xmpp transport? 😀

  346. lovetox

    so lets recap this, instead of the participant list in the muc i show a thread list, the client has MAM so gets all backlog, the muc is moderated, only people with voice can post (members) and maybe a server addon kicks people that dont identify with the correct client

  347. lovetox

    and you can only click on a thread and answer to a thread, never into the main muc

  348. SamWhited

    Does this mean there always ends up being an "offtopic" or "general" thread that's the new main muc?

  349. SamWhited

    (which is probably fine, just trying to nitpick things that feel odd)

  350. lovetox

    there is no main muc

  351. lovetox

    you have to add a thread to post

  352. lovetox

    like on the mailing list

  353. lovetox

    i mean you could create a general thread

  354. lovetox

    which is probably the same as posting to the main muc

  355. lovetox

    could we not even write a application on the server that transforms the stanzas and groups them via threads, for a webview

  356. lovetox

    wonder that nobody did something like that already

  357. Ge0rG

    lovetox: sounds like a web forum to me

  358. lovetox

    yeah though via xmpp :D

  359. Ge0rG

    Yeah, let's reinvent a bad clone of NNTP over XML

  360. SamWhited wishes he could just have his usenet back and be done with it.

  361. SouL

    Forum + xmpp, would be really cool

  362. Ge0rG

    SamWhited: Yeah! But it'll never come back.

  363. Ge0rG

    😟

  364. SamWhited

    Indeed; when I was in school we had free usenet on the campus network; it was great. All the clubs and frats and what not got issued a git.sga.yourclub or something (not that anyone ever used it; the theater did a bit for whatever reason though); but sometime during my junior year the guy who had built the system in the 90's came back to work at the school, was suprised to still find it running, and shut it down. It was very sad.

  365. Ge0rG

    We had a sat feed during the second half of the 90ies, it was awesome. Then the feed provider went bankrupt

  366. SamWhited

    The problem with usenet in a nutshell… everyone who tried to run the infrastructure decided to synchronize alt.binaries or whatever, and then went bankrupt :)

  367. jonasw

    :D

  368. Ge0rG

    SamWhited: that's because every user wanted alt.binaries ...

  369. Ge0rG

    And nothing else

  370. Flow

    jonasw: any particular reason the ecaps2 example uses BombusMod?

  371. Flow

    :)

  372. jonasw

    Flow: i think I even mention how I picked the examples

  373. jonasw

    ("first one in my capsdb which has this and that thing I want to show in that particular example")

  374. Flow

    jonasw: ok, I obviously didn't read that

  375. jonasw

    I knew people would wonder that :-)

  376. Flow

    is BombosMod still acticely developed?

  377. jonasw

    I have no idea.

  378. jonasw

    I am open to choosing different examples if it matters.

  379. Flow

    no, was just wondering

  380. Flow

    I do like what I read in ecaps2 so far

  381. jonasw

    that’s nice to hear :)

  382. Flow

    did you already get feedback from wasqas?

  383. jonasw

    I don’t think so

  384. jonasw

    should probably ping him directly

  385. Flow

    why not, I don't think he would mind

  386. Flow

    jonasw: Once this is accepted, you should add references to the RFCs for UTF-8 and base64

  387. jonasw

    right, I’ll add it to my notes

  388. Flow

    using hashes:hash is also uncommen, but likely not invalid XMPP, but I wonder how many XMPP libs would break

  389. jonasw

    right, quite a few

  390. jonasw

    might adapt that example, even though it’s valid.

  391. jonasw

    makes it shorter to read though

  392. jonasw

    note also that in the wire format examples, I use xmlns="…" instead of prefixes

  393. Flow

    jonasw: also possible s/Append a "."./append a FULL STOP character (U+002E, ".")/, which would be how RFCs reference characters

  394. jonasw

    that sounds better

  395. jonasw

    noted

  396. SamWhited

    ooh, I didn't actually notice that. FWIW, I would have -1ed it if I did.

  397. SamWhited

    I obviously didn't read this carefully enough :)

  398. jonasw

    SamWhited: which exactly?

  399. SamWhited

    Use of namespace prefixes

  400. jonasw

    uh

  401. Flow

    what's wrong with namepsace prefixes?

  402. jonasw

    didn’t know that it was such a red flag. it’s not even in a wire format example though.

  403. SamWhited

    Ah, yah, reading over this and it doesn't look like they're required, just part of the example so I don't care as much. But yah, I deeply hate them.

  404. Flow

    SamWhited: I don't think that you hate them is a valid reason to -1 a ProtoXEP

  405. jonasw

    I like them. of course I don’t require them, because at the layer we’re working at, there’s nothing we can do to require them, really :-)

  406. SamWhited

    Nothing handles namespaces properly, and I constantly have to fight with the fact that stream's use prefixes and if you don't do it stuff breaks even if your stuff is technically still valid

  407. jonasw

    s/Nothing/Nothing you use/

  408. jonasw

    libxml and expat handle them just fine

  409. Flow

    We had the discussion to introduce a generic 'by' attribute using a prefix which gets re-used by other XEPs

  410. SamWhited

    Yah, fair; nothing I use. But as far as I can tell libxml2 and expat are just about the only things that handle them fine

  411. Flow

    And I still like the idea

  412. jonasw

    frankly I don’t understand what’s so hard about handling XML namespaces in parsing or serialisation.

  413. SamWhited

    It's not "hard" there are just too many edge cases because there are so many ways to represent the same data

  414. SamWhited

    Which leads to bugs

  415. SamWhited

    At least, that was my take from briefly playing around with creating a namespace aware XML parser

  416. SamWhited

    But personally I think we shouldn't encourage the use of namespace prefixes, it will just lead to interoperability issues. Just keep it simple.

  417. jonasw

    Personally I think we shouldn’t cater for broken XML implementations.

  418. SamWhited

    I agree in principle, but not in practice.

  419. jonasw

    but I bow to reality

  420. lovetox

    if i send a message out to my own bareJID, will i always get the message back at the sending resource? or could the server choose another resource?

  421. lovetox

    Ge0rG,

  422. dwd

    lovetox, It's the same as any other message to your bare jid, and will be routed to one or more resources as per RFC 6121.

  423. Zash

    What have you people been up to today?

  424. lovetox

    that is a bit vague

  425. lovetox

    deliver the message to the "most available" resource or resources (according to the server's implementation-specific algorithm, e.g., treating the resource or resources with the highest presence priority as "most available")

  426. lovetox

    thats my question, is the resource that sends the message out also the "most available" in that moment

  427. lovetox

    so can i assume it will always get it back and not another resource

  428. Zash

    -xep best practices for resource locking

  429. dwd

    lovetox, Implementation-defined.

  430. Kev

    FWIW, we've had a long-standing stance to avoid namespaced attributes in the XMPP community.

  431. Kev

    On the basis that it's likely to break lots of things.

  432. Kev

    And that's about all I've got the energy to read up and notice.

  433. dwd

    Wait, namespaced *attributes*? I hadn't realised it was attributes. Nobody understands those (to a first approximation).

  434. Zash

    What's attributes?

  435. dwd

    Oh. It's not. It's just a prefixed element, albeit with the prefix defined in a containing element. That's fine, and I see nothign wrong in that.

  436. Kev

    It is? I thought someone said about namespaced attributes.

  437. dwd

    Assumign the "hashes:hash" comment is referring to the bit just above https://xmpp.org/extensions/inbox/ecaps2.html#usecases

  438. dwd

    I can't see anythign using namespaced attributes in there.

  439. dwd

    Also, I cannot type.

  440. Kev

    Ah, this is ecaps, not ISR?

  441. Kev

    I've just checked, they seem to be heavily used in ISR.

  442. Kev

    e.g. <enabled xmlns='urn:xmpp:sm:3' xmlns:isr='urn:xmpp:isr:0' isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52' isr:location='isr.example.org:5222'/>

  443. Ge0rG

    lovetox:

  444. Kev

    Which is what I understand by the term 'namespaced attribute', at least.

  445. Ge0rG

    You are totally

  446. dwd

    Oh, I've been staring at that recently and didn't notice them.

  447. Ge0rG

    breaking my highlights.

  448. dwd

    Ge0rG, You should have them done at my place, that Julian he does my hair lovely.

  449. Ge0rG

    lovetox: there is no guarantee that you will receive the Self-JID message, unless you send it to your own full JID. But you will probably receive the carbon, unless you are on m-link,which is now breaking expectations by doing the right thing

  450. Ge0rG

    And this is why everything in XMPP is complicated.

  451. lovetox

    thats the problem i found out just now

  452. lovetox

    if the server doesnt sent it back to the sending resource

  453. lovetox

    the resource that gets the message, gets also a "sent" carbon

  454. lovetox

    so double message again

  455. lovetox

    and this time i can only deduplicate if i go to the db and see if the stanza id is already there

  456. Ge0rG

    lovetox: the best thing to do is to rely on 0198 acks and filter out the duplicate

  457. Ge0rG

    lovetox: yes, unless you already got the same stanza id some time in the past

  458. lovetox

    gajim uses uuid

  459. Ge0rG

    My MUC code used to rely on unique stanza ids, it was a bad idea

  460. Ge0rG

    lovetox: okay, if you only ever t check an ID generated by gajim, you'll be fine

  461. lovetox

    but thats a lot of work to get self messaging to what i want it to be :/

  462. Ge0rG

    lovetox: the good thing is that you are probably guaranteed to receive the message and the carbon right after each other.

  463. lovetox

    yeah its actually not a problem right now, because gajim has a mechansim in which it caches a hash of various message attributes, and drops messages with the same hash

  464. Ge0rG

    That sounds like somebody could exploit it

  465. lovetox

    to what end?

  466. Ge0rG

    lovetox: to prevent you from seeing messages?

  467. lovetox

    you can only achieve the same hash when you write the same message

  468. lovetox

    so i dont want to see that

  469. Ge0rG

    lovetox: is it a cryptographic hash?

  470. lovetox

    sha256

  471. lovetox

    you would have to put in real effort to not let me see that message

  472. lovetox

    you could also just not write it :D

  473. lovetox

    ok have to go, good night :)