XSF logo 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 yes
  55. pep. ok
  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. Ah
  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 yes
  82. pep. ugh
  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. Brb
  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 https://github.com/iNPUTmice/talks/blob/master/2018_11_14_-_the_making_of_a_new_feature.md#to-roster-or-not-to-roster
  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 true
  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. hmm
  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. True
  206. Daniel or we put that in MAM :-)
  207. pep. :/
  208. pep. What don't we put in MAM nowadays
  209. Ge0rG MUC.
  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 What
  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 mod_mam_smart?
  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. k
  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 Alright
  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. post_post_process_messages
  268. Ge0rG mod_aggregate_receipts_and_markers
  269. pep. mod_mam_plus
  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 No
  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. :D
  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. Right
  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. yeah
  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 Correct
  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