jdev - 2019-09-08


  1. allie

    hi all :) this might be a silly question... but I'm playing around with trying to write a component (or something to that effect). anyway, is there any guidance/suggestions on when something should be a component and when it should be client/bot?

  2. allie

    trying to figure out how all this stuff sorta fits together

  3. Daniel

    allie, as a matter of fact i did write something on that: https://github.com/xmpp-docs/simple-muc-component-java/blob/master/README.md

  4. Daniel

    the rest of the tutorial isn’t done. but the client vs component section is

  5. pep.

    How would I know I've received a directed presence from someone?

  6. pep.

    I start receiving presences from somebody not in my roster? that's it?

  7. pep.

    when do I stop receiving directed presences? What does the sender need to do? Send an unavailable presence?

  8. lovetox

    yes

  9. pep.

    ok

  10. lovetox

    hm but i dont know what the server actually does

  11. lovetox

    if i send a directed presence, does the server then route all my status changes to that contact from that moment on?

  12. pep.

    I guess so?

  13. lovetox

    or is it like i have to take myself care of all directed presences

  14. lovetox

    but what if i send a contact a different show/status then my other contacts

  15. lovetox

    this is totally a use case

  16. lovetox

    maybe Zash knows ^

  17. Zash

    You get to do presence broadcasts manually for directed presence.

  18. pep.

    Ah

  19. pep.

    hmm so there's less privacy issues than I though

  20. pep.

    hmm so there's less privacy issues than I thought

  21. pep.

    I thought the server would actually forward all my status changes etc.

  22. lovetox

    yeah what i thought, everything else would not work

  23. lovetox

    one of the usecases for directed presence is, that i can show a different status/show to a contact

  24. lovetox

    so this would no fly if the server just broadcasts all my status changes

  25. pep.

    For me here it's the PEP updates use-case. I'm trying to come up with an update on that thread

  26. lovetox

    i didnt really get that, you want notifications from a contact not in your roster?

  27. pep.

    https://mail.jabber.org/pipermail/standards/2019-August/036367.html that's the thread, and yes

  28. pep.

    I'd want to allow people who can see my presence after me sending a directed presence, receive PEP updates for nodes they've expressed an interest for (+notify), for items with access_model=open

  29. pep.

    Hmm, that means I also need to have the other side's presence though no? :/

  30. pep.

    To get the caps

  31. lovetox

    not you

  32. lovetox

    the server

  33. lovetox

    and he can always query the contact if he needs to

  34. pep.

    Are caps available to anybody who asks?

  35. lovetox

    yes

  36. pep.

    ugh

  37. lovetox

    i mean depends on your client, a client could as well not answer a disco info request

  38. pep.

    You can ask a barejid no?

  39. pep.

    Or always fulljid?

  40. lovetox

    i guess you can ask a barejid

  41. lovetox

    but you will always get a answer from a fulljid

  42. lovetox

    in the contact case

  43. pep.

    You'll get an answer from a random fulljid?

  44. lovetox

    no you cant get an answer from a fulljid

  45. pep.

    > lovetox> but you will always get a answer from a fulljid

  46. lovetox

    server will always add a from with a resource

  47. lovetox

    ah sorry

  48. lovetox

    thought about barejid

  49. lovetox

    yes probably from all fulljids currently online

  50. lovetox

    or do IQs to contacts always need to be to fulljid?

  51. lovetox

    i dont know the routing rules

  52. lovetox

    where does a server route a IQ with no resource

  53. lovetox

    could be he doesnt at all

  54. pep.

    Ok that'd be what I expect I guess. Bob sends directed presence to Alice, requests Alice's caps on the barejid, it happens one of Alice's devices has foo+notify, and Bob has a foo node with open items

  55. pep.

    So Bob's server pushes that to Alice

  56. lovetox

    Zash ^

  57. lovetox

    but pep. i think you get yourself in a very complex situation that will not work good all the time

  58. lovetox

    its easier to just add the contact to your roster

  59. pep.

    Yeah that won't happen :x

  60. pep.

    Not for me at least

  61. lovetox

    so how long do you send directed presences?

  62. lovetox

    say you have a convo with a contact not in your roster

  63. lovetox

    you do your presence thing

  64. lovetox

    now you restart your client, what now?

  65. pep.

    Yeah, read the thread on standards, that's also one of my questions

  66. lovetox

    again sending directed presence? for how long goes that on? until the end of time?

  67. Daniel

    the end of the session

  68. pep.

    Sure, probably

  69. lovetox

    Daniel why though? one can argue that the chances of a device switch within a session is near zero

  70. lovetox

    you dont need notifications for that

  71. pep.

    Except when it's not

  72. pep.

    And then you get users complaining

  73. lovetox

    yeah sure, getting notifications only until you restart your client once, sounds like its surley work fine

  74. pep.

    As I don't add people in my roster that easily I suspect it'll be the case for me as well

  75. lovetox

    what you need is a local roster

  76. lovetox

    local roster of contacts which are not in your server roster

  77. Daniel

    pep., but why are you fine with having your client (automatically) send directed presence for all open conversations but not simply asking for mutual presence sub?

  78. lovetox

    then you can delete a contact from your local roster once you dont need him anymore, and can stop the presence thing

  79. pep.

    Daniel: it's not permanent right?

  80. pep.

    I can close the tab and be done with it

  81. Daniel

    if privacy is a concern (which i get but might not share) subbing to pep seems like the only option

  82. lovetox

    yeah why send directed presence, and not just sub to the node?

  83. lovetox

    those subscriptions you could track and manage

  84. pep.

    Not sure yet.

  85. pep.

    lovetox: tracking-wise it's the same

  86. pep.

    I need to know when to unsubscribe, same as I need to know when to send unavailable

  87. lovetox

    as i suggested make something like a local roster

  88. pep.

    Sure, that's an implementation detail

  89. lovetox

    then you know for all contacts in that local roster you can do X

  90. lovetox

    like sub on start of the session

  91. lovetox

    or send directed presence

  92. lovetox

    but you thought that only through into one direction

  93. lovetox

    if you want to send messages

  94. lovetox

    but the other way around will break easily

  95. lovetox

    only if you send someone your presence, it does not mean he gets updates when you change your devices

  96. lovetox

    or does it Oo?

  97. pep.

    When to subscribe is fine I guess. When to unsubscribe is a bit more annoying but also doable. When tab closes, on disconnect, and later when seeing a foreign PEP update

  98. lovetox

    no i dont think so

  99. pep.

    No it's not a thinf

  100. pep.

    No it's not a thing

  101. pep.

    I was going to maybe change that in PEP, just trying to see if it's worth it or not

  102. lovetox

    still see no benefit in this solution, i just add a contact to my roster and delete him if i dont want to talk anymore

  103. lovetox

    thats 2 clicks

  104. lovetox

    and zero implementation work

  105. pep.

    It's a bit less of a bother for a client to just send a directed presence I guess

  106. pep.

    Sure you still have to track who you're sending to

  107. pep.

    And you go through roster subscription flow and that's quite a pain for the user

  108. lovetox

    no you are trying to implement a solution that will not work 100% of the time, and needs code changes in your client, and i heard no gain sofar

  109. lovetox

    then make the roster subscription flow easier? actually it should just be one click

  110. lovetox

    there is no need to bother the user with more

  111. Zash

    So much text

  112. pep.

    Then you need to go to your roster when you're done and delete it :x

  113. Zash

    lovetox [13:14]: > i guess you can ask a barejid you can't

  114. pep.

    Brb

  115. pep.

    That's annoying

  116. Daniel

    i mean both managing directed presence and managing pep subscription seem like a pain in the ass

  117. Daniel

    however one of those is available now without changes to the XEP

  118. Daniel

    and to servers

  119. lovetox

    pep. then add something so its not annyoing

  120. lovetox

    like a button "Add contact temporary to roster"

  121. lovetox

    which means the client will delete it automatically from the roster after X days

  122. lovetox

    or at the start of the next session

  123. lovetox

    seems much nicer to go the direction of automating this adding/deleting roster stuff

  124. Daniel

    well there is also an alternate universe where roster means 'open conversations' (and not phone book)

  125. Daniel

    that then would also act as a way to sync 'open conversations'

  126. Daniel

    and you wouldn’t publish you entire 'address book' to the server but only 'open conversations'

  127. Daniel

    so if you close a tab you remove that person from the roster

  128. pep.

    When do we finish that inbox xep

  129. pep.

    Ok so.. conclusion, we manually subscribe to PEP and that's it?

  130. Ge0rG

    lovetox: never touch my roster without asking me. It's *my* roster, not yours.

  131. Ge0rG

    pep.: BTW, how do you synchronize that state between multiple clients?

  132. pep.

    You don't? Every client does its own magic :/

  133. pep.

    Not that I wouldn't like to have that

  134. pep.

    That's an interesting question though

  135. Ge0rG

    If only we had account side pep subscription management

  136. Daniel

    the second half of my Quicksy talk was about all that

  137. Daniel

    nobody cared back then :-)

  138. pep.

    Alice receives a message from Bob (who isn't in her roster) on her mobile and her desktop at the same time. She sees the message on the desktop but closes the tab and takes the discussion on the mobile because she's moving.

  139. pep.

    What do I do now.. One device will probably unsubscribe PEP, the other still needs it

  140. Daniel

    https://github.com/iNPUTmice/talks/blob/master/2018_11_14_-_the_making_of_a_new_feature.md#to-roster-or-not-to-roster

  141. Daniel

    i mentioning that because i already went to the thought process

  142. pep.

    Daniel, with multiple devices I'll have the same issue as bookmarks though..

  143. pep.

    I don't have the same usage of my phone and poezio :/

  144. pep.

    And then it's useless again

  145. Daniel

    true

  146. pep.

    Unless the XEP has profiles etc., but I doubt we'll go that way

  147. pep.

    Also if you use that XEP with a device and then you forget about it, you'll be subscribed to all the open discussions for eternity :p

  148. pep.

    (with profiles)

  149. pep.

    Currently, if we choose to subscribe to PEP manually, I see easy fails with multiple devices as I mentioned above

  150. pep.

    One will subscribe, you'll receive a notification, another one will unsubscribe because they don't know who that's coming from, etc.

  151. Daniel

    you can probably sub with your full jid to avoid that

  152. pep.

    hmm

  153. pep.

    That's handled by your server then? Or do all these queries get to the recipient's server?

  154. Daniel

    but also direct sub will only nofiy you when the change occurs while you are online

  155. pep.

    (As in your server subscribes for you with your barejid, and only sends to the subscribed fulljib)

  156. pep.

    True

  157. Daniel

    or we put that in MAM :-)

  158. pep.

    :/

  159. pep.

    What don't we put in MAM nowadays

  160. Ge0rG

    MUC.

  161. Daniel

    Only speak for yourself

  162. pep.

    I want to say <presence/> :-°

  163. Zash

    Chat states in presence?

  164. Ge0rG

    Chat states make up a frighteningly big part of my MAM download

  165. Zash

    What

  166. Zash

    I remember that being the case, so I made mod_mam strip them by default (+ configurable whatever namespaces)

  167. Ge0rG

    Zash: also empty messages from jitsi that only contain a thread

  168. Ge0rG

    Zash: I'll run another sync job and give you the Smack class names of the elements in body-less messages

  169. Zash

    Ge0rG: Does it send it like that?

  170. Zash

    thread + chat-state I can believe, but only thread? wut

  171. Ge0rG

    Zash: all I have is MAM

  172. Ge0rG

    Somebody broke the xml log in poezio, and android hardly remembers the last half an hour

  173. pep.

    Ge0rG, it's back on master

  174. pep.

    For 2 weeks now

  175. Ge0rG

    pep.: that's less than my poezio uptime.

  176. Ge0rG

    Since we fixed the memory leak, there are no excuses left for restarting. Okay, actually there's one left, when my ISP fails and then the automatic reconnect fails as well.

  177. Zash

    Why are there carbons in my archive?

  178. Zash

    35% of all xmlns attributes are chat states

  179. Ge0rG

    Zash: reduce your carbon footprint!

  180. Ge0rG

    As opposed to Carbons, MAM won't tell you if a message is outgoing or incoming. This is a real consistency problem with self messaging.

  181. Zash

    but https://hg.prosody.im/trunk/rev/93a068ef4b2c

  182. Zash

    Most of them are from before that tho

  183. Ge0rG

    Zash: how is this possibly a thing that a server operator would want to care about?

  184. Zash

    How am I supposed to know beforehand what should be archived and what shouldn't?

  185. Ge0rG

    Read all the XEPs. Make informed decisions. Bitch on standards@.

  186. Zash

    And then things change again.

  187. Ge0rG

    Zash: you can't have config variables for all the things that might change.

  188. Zash

    The list of plugins is the ultimate config variable for all things that will change.

  189. Ge0rG

    And you have SCM for the code, with one central repository. Imagine thousands of server admins trying to keep up with the latest and greatest value for each config variable.

  190. Ge0rG

    mod_mam_smart?

  191. Zash

    Actually it should just store everything and then do filtering when you query.

  192. Ge0rG

    Please don't.

  193. Zash

    And whatever happened to chat states in presence?

  194. Ge0rG

    It should do filtering based on the advertised client features, yes, but it really shouldn't store ephemeral junk like chat states

  195. Ge0rG

    Zash: nothing yet

  196. Ge0rG

    Zash: write the XEP!

  197. Zash

    My own server strips receipts, chat markers, hints, .... fight me.

  198. pep.

    Right, you don't need hint to store in MAM once they're in MAM. Shouldn't that be the default? :p

  199. pep.

    (not to store them)

  200. Zash

    Strip chat states. Realize archive is 90% chat markers. Strip those, etc.

  201. Zash

    Ask for 50 messages, get two with actual content.

  202. Zash

    Much fun.

  203. Ge0rG

    Zash: receipts and markers actually make sense

  204. pep.

    Zash, do you also not store messages that are empty after you've stripped things?

  205. Zash

    pep., yes, that's how it knows there wasn't anything useful in them

  206. pep.

    k

  207. Zash

    And why a message with only a <thread> could make it in there, if it also had a chat state

  208. Ge0rG

    Zash: why don't you store the unstripped version if the stripped one isn't empty?

  209. Zash

    Smaller storage footprint?

  210. Zash

    Less data to send when you query

  211. Ge0rG

    Alright

  212. Ge0rG

    Just that you might end up with only a thread element in MAM

  213. Ge0rG

    And you shouldn't completely strip that out

  214. Zash

    What would you do do with a thread and a chat state?

  215. pep.

    You should have a smarter module and remove stuff that doesn't make sense anymore once you've processed all you wanted to remove :P

  216. Zash

    I should say patches welcome.

  217. pep.

    :)

  218. pep.

    post_post_process_messages

  219. Ge0rG

    mod_aggregate_receipts_and_markers

  220. pep.

    mod_mam_plus

  221. Zash

    Isn't that the great plan already? MAM2

  222. pep.

    Not mam:2 right

  223. Zash

    No

  224. Zash

    MAM reimagined as some sort of multidimentional magic thing where each message has its own archive of addon-data

  225. pep.

    Yeah I know. Andrew Nenakhov even ranted about that on standards yesterday?

  226. Zash

    Hm? I'm referring to last Summit discussions

  227. Zash

    No wait, not an archive per message. An archive per extension per message.

  228. pep.

    Yeah, that was also discussed a few days ago in xsf@, alongside fastening

  229. Ge0rG

    Also summaries of attached messages

  230. Ge0rG

    <message type='chat' xml:lang='en' to='georg@yax.im/yaxim' id='7c0c163405834bfdb605eaf09333caa3' from='poezio@muc.poez.io/occupant'><origin-id id='7c0c163405834bfdb605eaf09333caa3' xmlns='urn:xmpp:sid:0'/><x xmlns='http://jabber.org/protocol/muc#user'/></message>

  231. Ge0rG

    Zash: I end up with more worthless messages in MAM: ^

  232. Ge0rG

    Zash: you can't strip <x/> or <origin-id/> from stored messages, but you can ignore them for the sake of storing messages.

  233. Ge0rG

    Zash: so you need that split-logic after all

  234. Zash

    Doing other things and/or nothing today. Please open an issue and write down the requirements, without mixing in different issues.

  235. allie

    Daniel: thanks for the link :) Although I'm still not 100% clear on when one should implement one or the other, unless the component is adding additional XEPpy features to the server. In those cases it seems it makes perfect sense. I guess it's a little confusing since, in the past, people have created components for things that didn't really need components.

  236. allie

    I just want to write something that provides weather information to me and other users when requested. That seems like it'd be in bot territory, since it doesn't need to modify JIDs, isn't extending the server, etc.

  237. Ge0rG

    allie: then write a bot

  238. allie

    yeah prolly what I'll do

  239. allie

    most of that was kinda thinking outloud :)

  240. Ge0rG

    You make a component if you want to bridge to a different chat network

  241. allie

    right, or I guess maybe pubsub-type stuff.

  242. pep.

    Ge0rG, that's not the only use-case, definitely.

  243. pep.

    You make a component if you need another addressing namespace(?)

  244. pep.

    You make a component if you need another addressing space(?)

  245. Ge0rG

    Is there a reason to do pubsub on a component instead of on a bot?

  246. Ge0rG

    pep.: yes, that's the abstract way to say it. But where else do you actually need that?

  247. pep.

    I guess a component is also easier to bundle with the server usually

  248. pep.

    You could very well have a pubsub bot running on the server? :p

  249. allie

    or like I was saying earlier if you're extending server functionality with another XEP

  250. pep.

    Ge0rG, though, a bot wouldn't appear in the server's disco#items would it?

  251. pep.

    Maybe not impossible to add it there.

  252. allie

    I've been an xmpp user off and on for years. but never tried to make anything for it. so that's why I'm still feeling my way through the different parts, and if you're going by how others have implemented things, I guess they've sometimes implemented things in certain ways that may have been better in other ways

  253. Ge0rG

    pep.: ask jonas’ if you really dare

  254. pep.

    :D

  255. pep.

    allie, sure some ways might be more appropriate than others :)

  256. pep.

    Ge0rG, just like you can have a MUC component on a barejid? :)

  257. Ge0rG

    pep.: yes.

  258. Zash

    Aha, found the post I was reminded of: https://metajack.im/2008/08/04/thoughts-on-scalable-xmpp-bots/

  259. pep.

    So why would you make a component if you don't need the addressing space?

  260. pep.

    Can you call a component that doesn't make use of that space a bot?

  261. Zash

    You can call it whatever you want, it's all arbitrary anyways

  262. allie

    I guess it's more that clients have lots of baggage that may not be appropriate for a component, whereas a component may as well be an entirely separate xmpp server that manages all its own stuff internally

  263. pep.

    Zash, not sure why the roster would be a problem at all. Just don't use it? :/

  264. pep.

    The component still needs to keep a mapping anyway

  265. Zash

    You can cheat if you do it yourself

  266. pep.

    Right

  267. pep.

    Also nothing says a component has to have only one role, right?

  268. pep.

    (That is, MUC, pubsub, user domain?!, etc.)

  269. pep.

    mod_pubsub could even be loaded on the vhost right?

  270. Zash

    Remember the special user@host component thing Prosody supports?

  271. Ge0rG

    pep.: some client libraries seem to have very strong opinions on that

  272. pep.

    Ge0rG, open bugs!

  273. Zash

    pep., as long as they don't conflict in the namespaces and stuff they use. Eg disco gets funky sometimes.

  274. Ge0rG

    pep.: BTDT

  275. pep.

    hmm right disco

  276. pep.

    I would have liked this <feature><feature/></feature> thing to happen :P

  277. Zash

    pep., but you're right, there's no problem with having pubsub and stuff on a normal host. MUC is problematic tho, since it overloads nodeparts

  278. pep.

    yeah

  279. pep.

    But I'm sure users and rooms can coexist. They can find a way to live in peace

  280. Zash

    Why can't users be rooms? And why can't rooms join users?

  281. pep.

    Such a philosophical question

  282. Zash

    Like DMUC (?) where MUCs join other MUCs and you get IRC-style trees

  283. pep.

    I was actually planning to look into that

  284. pep.

    That is, adding it on the TODO

  285. Ge0rG

    A client needs different code paths for messages from a MUC vs from a user. You can't have both on the same bare JID

  286. allie

    Zash: MUCs all the way down...

  287. pep.

    A room cannot be on a FullJid right? Otherwise there's no place for nicks anymore(?)

  288. Zash

    Correct