jdev - 2019-09-08

  1. bhaveshsgupta has joined

  2. allie has joined

  3. 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?

  4. allie

    trying to figure out how all this stuff sorta fits together

  5. bhaveshsgupta has left

  6. aj has joined

  7. bhaveshsgupta has joined

  8. bhaveshsgupta has left

  9. bhaveshsgupta has joined

  10. bhaveshsgupta has left

  11. bhaveshsgupta has joined

  12. lksjdflksjdf has left

  13. lksjdflksjdf has joined

  14. bhaveshsgupta has left

  15. bhaveshsgupta has joined

  16. ͡ ͡ has joined

  17. ͡ ͡ has left

  18. lksjdflksjdf has left

  19. allie has left

  20. lksjdflksjdf has joined

  21. Daniel has left

  22. Daniel has joined

  23. Daniel has left

  24. lksjdflksjdf has left

  25. bhaveshsgupta has left

  26. bhaveshsgupta has joined

  27. aj has left

  28. bhaveshsgupta has left

  29. bhaveshsgupta has joined

  30. Daniel has joined

  31. 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

  32. Daniel

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

  33. linkmauve has joined

  34. lovetox has joined

  35. Alex has joined

  36. rion has left

  37. rion has joined

  38. bhaveshsgupta has left

  39. bhaveshsgupta has joined

  40. larma has left

  41. larma has joined

  42. bhaveshsgupta has left

  43. bhaveshsgupta has joined

  44. aj has joined

  45. bhaveshsgupta has left

  46. bhaveshsgupta has joined

  47. ͡ ͡ has joined

  48. ͡ ͡ has left

  49. bhaveshsgupta has left

  50. bhaveshsgupta has joined

  51. pep.

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

  52. pep.

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

  53. pep.

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

  54. lovetox


  55. pep.


  56. lovetox

    hm but i dont know what the server actually does

  57. lovetox

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

  58. pep.

    I guess so?

  59. lovetox

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

  60. lovetox

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

  61. lovetox

    this is totally a use case

  62. lovetox

    maybe Zash knows ^

  63. Zash

    You get to do presence broadcasts manually for directed presence.

  64. pep.


  65. pep.

    hmm so there's less privacy issues than I though

  66. pep.

    hmm so there's less privacy issues than I thought

  67. pep.

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

  68. lovetox

    yeah what i thought, everything else would not work

  69. lovetox

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

  70. lovetox

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

  71. pep.

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

  72. lovetox

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

  73. pep.

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

  74. 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

  75. pep.

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

  76. pep.

    To get the caps

  77. lovetox

    not you

  78. lovetox

    the server

  79. lovetox

    and he can always query the contact if he needs to

  80. pep.

    Are caps available to anybody who asks?

  81. lovetox


  82. pep.


  83. lovetox

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

  84. pep.

    You can ask a barejid no?

  85. pep.

    Or always fulljid?

  86. lovetox

    i guess you can ask a barejid

  87. lovetox

    but you will always get a answer from a fulljid

  88. lovetox

    in the contact case

  89. pep.

    You'll get an answer from a random fulljid?

  90. lovetox

    no you cant get an answer from a fulljid

  91. pep.

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

  92. lovetox

    server will always add a from with a resource

  93. lovetox

    ah sorry

  94. lovetox

    thought about barejid

  95. lovetox

    yes probably from all fulljids currently online

  96. lovetox

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

  97. lovetox

    i dont know the routing rules

  98. lovetox

    where does a server route a IQ with no resource

  99. lovetox

    could be he doesnt at all

  100. 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

  101. pep.

    So Bob's server pushes that to Alice

  102. lovetox

    Zash ^

  103. lovetox

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

  104. lovetox

    its easier to just add the contact to your roster

  105. pep.

    Yeah that won't happen :x

  106. pep.

    Not for me at least

  107. lovetox

    so how long do you send directed presences?

  108. lovetox

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

  109. lovetox

    you do your presence thing

  110. lovetox

    now you restart your client, what now?

  111. pep.

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

  112. lovetox

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

  113. Daniel

    the end of the session

  114. pep.

    Sure, probably

  115. lovetox

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

  116. lovetox

    you dont need notifications for that

  117. pep.

    Except when it's not

  118. pep.

    And then you get users complaining

  119. lovetox

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

  120. pep.

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

  121. lovetox

    what you need is a local roster

  122. lovetox

    local roster of contacts which are not in your server roster

  123. 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?

  124. lovetox

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

  125. pep.

    Daniel: it's not permanent right?

  126. pep.

    I can close the tab and be done with it

  127. Daniel

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

  128. lovetox

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

  129. lovetox

    those subscriptions you could track and manage

  130. pep.

    Not sure yet.

  131. pep.

    lovetox: tracking-wise it's the same

  132. pep.

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

  133. lovetox

    as i suggested make something like a local roster

  134. pep.

    Sure, that's an implementation detail

  135. lovetox

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

  136. lovetox

    like sub on start of the session

  137. lovetox

    or send directed presence

  138. lovetox

    but you thought that only through into one direction

  139. lovetox

    if you want to send messages

  140. lovetox

    but the other way around will break easily

  141. lovetox

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

  142. lovetox

    or does it Oo?

  143. 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

  144. lovetox

    no i dont think so

  145. pep.

    No it's not a thinf

  146. pep.

    No it's not a thing

  147. pep.

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

  148. 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

  149. lovetox

    thats 2 clicks

  150. lovetox

    and zero implementation work

  151. pep.

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

  152. pep.

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

  153. pep.

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

  154. 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

  155. lovetox

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

  156. lovetox

    there is no need to bother the user with more

  157. Zash

    So much text

  158. pep.

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

  159. Zash

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

  160. pep.


  161. pep.

    That's annoying

  162. Daniel

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

  163. Daniel

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

  164. Daniel

    and to servers

  165. lovetox

    pep. then add something so its not annyoing

  166. lovetox

    like a button "Add contact temporary to roster"

  167. lovetox

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

  168. lovetox

    or at the start of the next session

  169. lovetox

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

  170. Daniel

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

  171. Daniel

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

  172. Daniel

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

  173. Daniel

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

  174. pep.

    When do we finish that inbox xep

  175. pep.

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

  176. Ge0rG

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

  177. Ge0rG

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

  178. pep.

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

  179. pep.

    Not that I wouldn't like to have that

  180. pep.

    That's an interesting question though

  181. Ge0rG

    If only we had account side pep subscription management

  182. Daniel

    the second half of my Quicksy talk was about all that

  183. Daniel

    nobody cared back then :-)

  184. 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.

  185. pep.

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

  186. Daniel


  187. Daniel

    i mentioning that because i already went to the thought process

  188. lksjdflksjdf has joined

  189. pep.

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

  190. pep.

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

  191. pep.

    And then it's useless again

  192. Daniel


  193. pep.

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

  194. 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

  195. pep.

    (with profiles)

  196. pep.

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

  197. pep.

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

  198. Daniel

    you can probably sub with your full jid to avoid that

  199. pep.


  200. pep.

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

  201. Daniel

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

  202. pep.

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

  203. larma has left

  204. larma has joined

  205. pep.


  206. Daniel

    or we put that in MAM :-)

  207. pep.


  208. pep.

    What don't we put in MAM nowadays

  209. Ge0rG


  210. Daniel

    Only speak for yourself

  211. pep.

    I want to say <presence/> :-°

  212. Zash

    Chat states in presence?

  213. Ge0rG

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

  214. Zash


  215. Zash

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

  216. Ge0rG

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

  217. Ge0rG

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

  218. Zash

    Ge0rG: Does it send it like that?

  219. Zash

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

  220. Ge0rG

    Zash: all I have is MAM

  221. Ge0rG

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

  222. pep.

    Ge0rG, it's back on master

  223. pep.

    For 2 weeks now

  224. Ge0rG

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

  225. 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.

  226. Zash

    Why are there carbons in my archive?

  227. Zash

    35% of all xmlns attributes are chat states

  228. Ge0rG

    Zash: reduce your carbon footprint!

  229. 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.

  230. Zash

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

  231. Zash

    Most of them are from before that tho

  232. Ge0rG

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

  233. Zash

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

  234. Ge0rG

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

  235. Zash

    And then things change again.

  236. Ge0rG

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

  237. Zash

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

  238. 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.

  239. Ge0rG


  240. Zash

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

  241. Ge0rG

    Please don't.

  242. Zash

    And whatever happened to chat states in presence?

  243. Ge0rG

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

  244. Ge0rG

    Zash: nothing yet

  245. Ge0rG

    Zash: write the XEP!

  246. Zash

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

  247. pep.

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

  248. pep.

    (not to store them)

  249. Zash

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

  250. Zash

    Ask for 50 messages, get two with actual content.

  251. Zash

    Much fun.

  252. Ge0rG

    Zash: receipts and markers actually make sense

  253. pep.

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

  254. Zash

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

  255. pep.


  256. Zash

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

  257. Ge0rG

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

  258. Zash

    Smaller storage footprint?

  259. Zash

    Less data to send when you query

  260. Ge0rG


  261. Ge0rG

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

  262. Ge0rG

    And you shouldn't completely strip that out

  263. Zash

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

  264. 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

  265. Zash

    I should say patches welcome.

  266. pep.


  267. pep.


  268. Ge0rG


  269. pep.


  270. bhaveshsgupta has left

  271. bhaveshsgupta has joined

  272. Zash

    Isn't that the great plan already? MAM2

  273. pep.

    Not mam:2 right

  274. Zash


  275. Zash

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

  276. pep.

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

  277. Zash

    Hm? I'm referring to last Summit discussions

  278. Zash

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

  279. pep.

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

  280. bhaveshsgupta has left

  281. Ge0rG

    Also summaries of attached messages

  282. bhaveshsgupta has joined

  283. rion has left

  284. rion has joined

  285. bhaveshsgupta has left

  286. bhaveshsgupta has joined

  287. bhaveshsgupta has left

  288. bhaveshsgupta has joined

  289. bhaveshsgupta has left

  290. bhaveshsgupta has joined

  291. Syndace has left

  292. Syndace has joined

  293. bhaveshsgupta has left

  294. bhaveshsgupta has joined

  295. Alex has left

  296. Alex has joined

  297. bhaveshsgupta has left

  298. bhaveshsgupta has joined

  299. bhaveshsgupta has left

  300. bhaveshsgupta has joined

  301. bhaveshsgupta has left

  302. bhaveshsgupta has joined

  303. bhaveshsgupta has left

  304. bhaveshsgupta has joined

  305. bhaveshsgupta has left

  306. 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>

  307. Ge0rG

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

  308. Ge0rG

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

  309. Ge0rG

    Zash: so you need that split-logic after all

  310. Zash

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

  311. bhaveshsgupta has joined

  312. linkmauve has left

  313. linkmauve has joined

  314. bhaveshsgupta has left

  315. bhaveshsgupta has joined

  316. bhaveshsgupta has left

  317. bhaveshsgupta has joined

  318. Lance has left

  319. aj has left

  320. Astro has joined

  321. allie has joined

  322. 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.

  323. 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.

  324. Ge0rG

    allie: then write a bot

  325. allie

    yeah prolly what I'll do

  326. allie

    most of that was kinda thinking outloud :)

  327. Ge0rG

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

  328. allie

    right, or I guess maybe pubsub-type stuff.

  329. pep.

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

  330. pep.

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

  331. pep.

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

  332. Ge0rG

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

  333. Ge0rG

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

  334. pep.

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

  335. pep.

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

  336. allie

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

  337. pep.

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

  338. pep.

    Maybe not impossible to add it there.

  339. 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

  340. Ge0rG

    pep.: ask jonas’ if you really dare

  341. pep.


  342. pep.

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

  343. pep.

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

  344. Ge0rG

    pep.: yes.

  345. Zash

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

  346. pep.

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

  347. pep.

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

  348. Zash

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

  349. 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

  350. pep.

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

  351. pep.

    The component still needs to keep a mapping anyway

  352. Zash

    You can cheat if you do it yourself

  353. pep.


  354. pep.

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

  355. pep.

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

  356. pep.

    mod_pubsub could even be loaded on the vhost right?

  357. Zash

    Remember the special user@host component thing Prosody supports?

  358. Ge0rG

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

  359. pep.

    Ge0rG, open bugs!

  360. Zash

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

  361. Ge0rG

    pep.: BTDT

  362. pep.

    hmm right disco

  363. pep.

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

  364. 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

  365. pep.


  366. pep.

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

  367. Zash

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

  368. pep.

    Such a philosophical question

  369. Zash

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

  370. pep.

    I was actually planning to look into that

  371. pep.

    That is, adding it on the TODO

  372. 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

  373. allie

    Zash: MUCs all the way down...

  374. Alex has left

  375. pep.

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

  376. Zash


  377. ͡ ͡ has joined

  378. allie has left

  379. Alex has joined

  380. bhaveshsgupta has left

  381. bhaveshsgupta has joined

  382. larma has left

  383. lovetox has left

  384. larma has joined

  385. allie has joined

  386. bhaveshsgupta has left

  387. bhaveshsgupta has joined

  388. larma has left

  389. larma has joined

  390. bhaveshsgupta has left

  391. bhaveshsgupta has joined

  392. linkmauve has left

  393. bhaveshsgupta has left