XSF Discussion - 2020-04-13


  1. andrey.g has left

  2. bear has joined

  3. pdurbin has joined

  4. aj has joined

  5. pdurbin has left

  6. bear has left

  7. karoshi has left

  8. emus has left

  9. emus has joined

  10. aj has left

  11. bear has joined

  12. lskdjf has left

  13. emus has left

  14. bear has left

  15. debacle has left

  16. bear has joined

  17. pdurbin has joined

  18. Maranda has left

  19. govanify has left

  20. bear has left

  21. pdurbin has left

  22. waqas has left

  23. waqas has joined

  24. Yagiza has joined

  25. aj has joined

  26. waqas has left

  27. waqas has joined

  28. xsf has left

  29. Maranda has joined

  30. govanify has joined

  31. waqas has left

  32. waqas has joined

  33. waqas has left

  34. waqas has joined

  35. aj has left

  36. andrey.g has joined

  37. waqas has left

  38. waqas has joined

  39. waqas has left

  40. waqas has joined

  41. xsf has joined

  42. waqas has left

  43. waqas has joined

  44. bear has joined

  45. pdurbin has joined

  46. bear has left

  47. murabito has left

  48. Seve has joined

  49. DebXWoody has joined

  50. bear has joined

  51. mimi89999 has left

  52. mimi89999 has joined

  53. DebXWoody has left

  54. DebXWoody has joined

  55. bear has left

  56. lorddavidiii has joined

  57. bear has joined

  58. Daniel has left

  59. Daniel has joined

  60. paul has joined

  61. Daniel has left

  62. Daniel has joined

  63. bear has left

  64. adiaholic_ has left

  65. adiaholic_ has joined

  66. waqas has left

  67. moparisthebest has left

  68. Daniel has left

  69. Daniel has joined

  70. bear has joined

  71. Daniel has left

  72. Daniel has joined

  73. bear has left

  74. Daniel has left

  75. Daniel has joined

  76. wurstsalat has left

  77. adiaholic_ has left

  78. adiaholic_ has joined

  79. Tobias has joined

  80. Maranda

    Hmm was WebSocket forgot on purpose? 👨‍💻🤔

  81. adiaholic_ has left

  82. adiaholic_ has joined

  83. wurstsalat has joined

  84. DebXWoody has left

  85. karoshi has joined

  86. bear has joined

  87. karoshi has left

  88. karoshi has joined

  89. DebXWoody has joined

  90. Daniel has left

  91. Daniel has joined

  92. Daniel has left

  93. Daniel has joined

  94. bear has left

  95. werdan has joined

  96. Daniel has left

  97. Daniel has joined

  98. werdan has left

  99. Daniel has left

  100. Daniel has joined

  101. werdan has joined

  102. werdan has left

  103. Daniel has left

  104. Daniel has joined

  105. Marc has joined

  106. Daniel has left

  107. Daniel has joined

  108. sonny has joined

  109. Daniel has left

  110. Daniel has joined

  111. bear has joined

  112. Daniel has left

  113. Daniel has joined

  114. Daniel has left

  115. Daniel has joined

  116. Daniel has left

  117. Daniel has joined

  118. larma has left

  119. DebXWoody has left

  120. DebXWoody has joined

  121. DebXWoody has left

  122. DebXWoody has joined

  123. lskdjf has joined

  124. DebXWoody has left

  125. DebXWoody has joined

  126. bear has left

  127. larma has joined

  128. Daniel has left

  129. Daniel has joined

  130. emus has joined

  131. robertooo has joined

  132. Daniel has left

  133. emus

    Maranda: Du musst dich klarer ausdrücken und am besten auf englisch. sonst geh mal hier hin:

  134. emus

    xmpp:xmpp-de@conference.conversations.im?join

  135. Daniel has joined

  136. andy has joined

  137. Jeybe has joined

  138. bear has joined

  139. mukt2 has joined

  140. emus has left

  141. Syndace

    what xD

  142. emus has joined

  143. Syndace

    Yeah Maranda, stop speaking such unclear german!!!

  144. lovetox has joined

  145. mukt2 has left

  146. j.r has left

  147. j.r has joined

  148. !XSF_Martin

    emus: afaik he is Italian so he'll probably not understand you, when you talk german.

  149. bear has left

  150. LNJ has joined

  151. emus

    Was early, somehow I took it for German, and the rest if it as an English quote, like: Hmm was? "WebSocket forgot on purpose?" now its more clear^^

  152. Maranda

    . . .

  153. !XSF_Martin

    😂

  154. Daniel

    Was are you taking about?

  155. !XSF_Martin

    Das should be clear now!

  156. Jeybe has left

  157. Jeybe has joined

  158. LNJ has left

  159. Zash has left

  160. Zash has joined

  161. LNJ has joined

  162. Daniel has left

  163. Daniel has joined

  164. flow

    Die Bart, Die

  165. emus

    Daniel: Misunderstanding, nevermind

  166. debacle has joined

  167. debacle has left

  168. debacle has joined

  169. werdan has joined

  170. debacle has left

  171. bear has joined

  172. debacle has joined

  173. debacle has left

  174. mukt2 has joined

  175. debacle has joined

  176. debacle has left

  177. debacle has joined

  178. debacle has left

  179. Daniel has left

  180. Daniel has joined

  181. debacle has joined

  182. mukt2 has left

  183. debacle has left

  184. debacle has joined

  185. debacle has left

  186. serge90 has joined

  187. debacle has joined

  188. bear has left

  189. debacle has left

  190. debacle has joined

  191. Daniel has left

  192. Daniel has joined

  193. Steve Kille has left

  194. Daniel has left

  195. Daniel has joined

  196. Steve Kille has joined

  197. Daniel has left

  198. Daniel has joined

  199. xsf has left

  200. goffi has joined

  201. Jeybe has left

  202. werdan has left

  203. lovetox has left

  204. Jeybe has joined

  205. sonny has left

  206. lovetox has joined

  207. j.r has left

  208. !XSF_Martin has left

  209. j.r has joined

  210. !XSF_Martin has joined

  211. bear has joined

  212. sonny has joined

  213. j.r has left

  214. j.r has joined

  215. bear has left

  216. andrey.g has left

  217. andrey.g has joined

  218. neshtaxmpp has joined

  219. pdurbin has left

  220. serge90 has left

  221. serge90 has joined

  222. serge90 has left

  223. serge90 has joined

  224. serge90 has left

  225. serge90 has joined

  226. werdan has joined

  227. serge90 has left

  228. serge90 has joined

  229. serge90 has left

  230. serge90 has joined

  231. goffi has left

  232. goffi has joined

  233. serge90 has left

  234. serge90 has joined

  235. serge90 has left

  236. serge90 has joined

  237. serge90 has left

  238. serge90 has joined

  239. bear has joined

  240. toystory has joined

  241. mukt2 has joined

  242. serge90 has left

  243. serge90 has joined

  244. toystory has left

  245. j.r has left

  246. j.r has joined

  247. mukt2 has left

  248. Daniel has left

  249. Daniel has joined

  250. Daniel has left

  251. Daniel has joined

  252. Daniel has left

  253. Daniel has joined

  254. moparisthebest has joined

  255. bear has left

  256. Daniel has left

  257. Daniel has joined

  258. Daniel has left

  259. Daniel has joined

  260. j.r has left

  261. j.r has joined

  262. j.r has left

  263. j.r has joined

  264. Daniel has left

  265. Daniel has joined

  266. calvin has joined

  267. Daniel has left

  268. Daniel has joined

  269. Shell has joined

  270. krauq has left

  271. krauq has joined

  272. Shell has left

  273. Shell has joined

  274. bear has joined

  275. mukt2 has joined

  276. adiaholic_ has left

  277. mukt2 has left

  278. bear has left

  279. rion has left

  280. rion has joined

  281. pdurbin has joined

  282. pdurbin has left

  283. serge90 has left

  284. serge90 has joined

  285. waqas has joined

  286. waqas has left

  287. lovetox has left

  288. lovetox has joined

  289. bear has joined

  290. bear has left

  291. adiaholic_ has joined

  292. Max has left

  293. Max has joined

  294. jonas’

    fun

  295. jonas’

    XEP-0191 says to discover support on the server, not on the account.

  296. jonas’

    https://xmpp.org/extensions/xep-0191.html#disco

  297. jonas’

    which is kind of meh if the feature isn’t offered on all accounts

  298. jonas’

    it’s in Draft. do we want to fix this?

  299. Daniel

    Yes

  300. jonas’

    alright, drafting a PR

  301. Daniel

    And/or offering on the server could maybe mean something different if you are the admin of that server

  302. jonas’

    the yaks, they need shaving

  303. Zash

    Like the hack I wrote where if a service admin blocks a bare host JID, s2s to/from that server is blocked?

  304. Daniel

    For example

  305. Zash

    I wouldn't mind 191 in MUCs (and MIX?) either.

  306. Zash

    Where's the XEP that descibes versioned namespaces?

  307. Zash

    Surely it's not just a ProtoXEP in Inbox? https://xmpp.org/extensions/inbox/nsver.html

  308. Zash

    Can't find anything with "namespace" or "version*" in the title tho

  309. jonas’

    probably XEP-0001 or XEP-0143?

  310. LNJ has left

  311. jonas’

    there we go: https://github.com/xsf/xeps/pull/924

  312. LNJ has joined

  313. Zash

    Lots of old things only advertise on the host JID

  314. Daniel

    I think in general it should be announced on the jid you'll end up talking to

  315. Zash

    Agree. Historical things tho.

  316. jonas’

    neat, prosody only advertises it on the domain

  317. Zash

    What's that, Prosody follows the specification? Oh no!

  318. jonas’

    no wait

  319. jonas’

    that’s me not having it loaded in my e2etest prosody

  320. Daniel

    For most things I just check both in Conversations 🤷‍♂️

  321. jonas’

    still not offered on the account though :(

  322. paul has left

  323. jonas’

    Daniel, fun fact, in openfire you may end up with a situation where the feature is advertised on the domain, but you can’t use it because it’s not enabled for your account.

  324. Zash

    jonas’: Prosody does what the current version of the XEP says, and it says to advertise on the host but you talk to the no-to/own account JID

  325. adiaholic_ has left

  326. adiaholic_ has joined

  327. jonas’

    Zash, not complaining

  328. jonas’

    just unhappy that I can’t resolve the issue I’m facing in any way right now

  329. Zash

    Write a 3 line module for it :P

  330. jonas’

    Zash, that doesn’t solve the actual issue (broken XEP-0191)

  331. Zash

    Fun

  332. Shell has left

  333. Shell has joined

  334. paul has joined

  335. bear has joined

  336. adiaholic_ has left

  337. adiaholic_ has joined

  338. Maranda has left

  339. david has left

  340. Shell has left

  341. Shell has joined

  342. bear has left

  343. Guus has left

  344. Guus has joined

  345. pdurbin has joined

  346. Wojtek has joined

  347. Nekit has left

  348. Daniel has left

  349. Daniel has joined

  350. Daniel has left

  351. Daniel has joined

  352. pdurbin has left

  353. Maranda has joined

  354. Daniel has left

  355. Daniel has joined

  356. Daniel has left

  357. Daniel has joined

  358. Daniel has left

  359. Daniel has joined

  360. Daniel has left

  361. Daniel has joined

  362. Daniel has left

  363. Daniel has joined

  364. Daniel has left

  365. Daniel has joined

  366. Daniel has left

  367. calvin has left

  368. calvin has joined

  369. david has joined

  370. Shell has left

  371. Shell has joined

  372. werdan has left

  373. mukt2 has joined

  374. bear has joined

  375. lorddavidiii has left

  376. lorddavidiii has joined

  377. mukt2 has left

  378. Daniel has joined

  379. bear has left

  380. paul has left

  381. paul has joined

  382. paul has left

  383. marc has left

  384. paul has joined

  385. eta has left

  386. eta has joined

  387. Wojtek has left

  388. Shell has left

  389. Shell has joined

  390. Wojtek has joined

  391. Shell has left

  392. Shell has joined

  393. Nekit has joined

  394. Wojtek has left

  395. Wojtek has joined

  396. Wojtek has left

  397. arc has joined

  398. Maranda

    I'm not sure what I do either...

  399. Maranda

    (for xep-0191)

  400. Maranda

    host disco#info together with the deprecated privacy lists

  401. mukt2 has joined

  402. andrey.g has left

  403. bear has joined

  404. marc has joined

  405. Daniel has left

  406. Daniel has joined

  407. mukt2 has left

  408. Seve has left

  409. Yagiza has left

  410. Seve has joined

  411. bear has left

  412. pdurbin has joined

  413. calvin has left

  414. calvin has joined

  415. Daniel has left

  416. Daniel has joined

  417. Wojtek has joined

  418. Daniel has left

  419. Daniel has joined

  420. flow

    Zash> Lots of old things only advertise on the host JID which is often the way to go IMHO

  421. Zash

    Advertising on the JID you talk to seems the sensible thing.

  422. flow

    Zash, makes it harder to get a survey which features are actually implemented, and I don't see an advantage

  423. Zash

    OTOH, the caps has you can send in stream:features doesn't cover features on your account.

  424. jonas’

    flow, the advantage is that a feature can be offered on a per-account basis

  425. jonas’

    without having to do terrible things to your disco#info handlers ;)

  426. flow

    I also think that the semantic of a feature annoucement is "this implementation does implement this feature", not "this feature is provided to your account"

  427. flow

    jonas’, I do not think that this is true

  428. Maranda

    and the use case of not providing blocking command to certain accounts is...?

  429. Maranda

    and the advantage of not providing blocking command to certain accounts is...?

  430. flow

    Maranda, I do not think that it is sensible to discuss specific extensions at this stage

  431. Maranda

    flow, but the whole discussion was about blocking command in the first place

  432. andrey.g has joined

  433. pdurbin has left

  434. flow

    Maranda, right, but it is something we should discuss in general

  435. flow

    because it is *everywhere* in xmpp

  436. flow

    and the discussion also appears every 2-3 years

  437. flow

    and the discussion where to announce features also appears every 2-3 years

  438. kevin has joined

  439. kevin has left

  440. Zash

    Let's schedule a 2-day discussion of it at Summit 2022 then!

  441. Zash

    The Final Discussion

  442. Maranda

    well flow while I see the benefit for other things, I think that extensions that sensibly shouldn't be offered on a per-account basis just should end with the features on the host.

  443. krauq has left

  444. goffi has left

  445. goffi has joined

  446. flow

    Maranda, I think there is some misunderstanding? I am also arguing in favor of annoucing features on the host (but for a different reason)

  447. arc has left

  448. arc has joined

  449. arc has left

  450. arc has joined

  451. werdan has joined

  452. Maranda

    flow, I don't think there's any misunderstanding tbh, just explaining why my comment wasn't completely... "unsensible", imho.

  453. kevin has joined

  454. flow

    Maranda, from PoV it is unsensible because I don't think that you can ever be 100% sure that a given feature will *always* provided to *all* users

  455. flow

    Maranda, from my PoV it is unsensible because I don't think that you can ever be 100% sure that a given feature will *always* provided to *all* users

  456. kevin has left

  457. flow

    but since I don't think that disco#info features are there to tell you if you are allowed to use a certain feature…

  458. Maranda

    ditto

  459. lovetox

    flow but then you have terible discovery of what you are allowed to use

  460. lovetox

    and thats what clients need everyday, compared to survey bots that look what server implement these days

  461. lovetox

    and thats about the only usecase i see for announcing anything on the host

  462. lovetox

    so in light that there is no perfect solution, lets go with what is needed by most people

  463. flow

    lovetox, yes I think we are really bad when it comes to discovering if one is allowed to perform action X. Just look at muc room creation for example

  464. flow

    but, annoucing a feature of muc#room_creation_allowed on the MUC jid is probably a terrible idea

  465. flow

    especially if it is returned depending on the entity which queries

  466. APach has left

  467. APach has joined

  468. flow

    disco#info results should not differ depending on the entity which issued the request

  469. lovetox

    why?

  470. flow

    well caps for one

  471. lovetox

    thats all? because that does not seem like such a big problem

  472. lovetox

    1. we have no caps for host anyway

  473. flow

    I think it is in general a bad pattern

  474. lovetox

    2. for muc service also not

  475. flow

    plus if you do it there, people will think it is a good idea to do the same with entities that broadcast caps

  476. lovetox

    yeah i agree flow, but in the absence of something better

  477. lovetox

    we have to use whats there

  478. Zash

    caps from the host can be in <stream:features>

  479. flow

    besides, if we further assume that "you are allowed to perform action X" may change over time, one may want a push mechanism for that, to inform clients

  480. andrey.g has left

  481. Zash

    like, an authz error reply if you try isn't enough?

  482. flow

    lovetox, I'd argue we use the force of XMPPs extensibility to create something suitable

  483. lovetox

    flow we dont have caps for host and services, so on every new start of a client you have to query anyway

  484. flow

    Zash, it is in most cases I think

  485. jubalh has left

  486. calvin has left

  487. lovetox

    and services and host dont change account features on a daily basis

  488. flow

    Zash, after all xep45 says not-allowed on room creation attempt, and I haven't heard someone asking for a feature to discover if an entity is allowed to create a room prior room creation

  489. lovetox

    so we can live with it

  490. flow

    that doesn't mean that something like that wouldn't be nice to have

  491. flow

    that doesn't mean that something like that wouldn't be nice to have though

  492. flow

    lovetox, as Zash said, we do have caps on xmpp services

  493. Zash

    But no caps for your own account features. :/

  494. adiaholic_ has left

  495. adiaholic_ has joined

  496. flow

    Zash, right, but I really think this shouldn't be called features then, but instead maybe "capabilities" (or something)

  497. bear has joined

  498. Zash

    I mean as in disco#info

  499. krauq has joined

  500. Maranda

    Zash, but if you advertise only on stream features clients will have to cache caps? (not that possibly they don't do that already)

  501. flow

    Zash, I know, and I mean that I think the mechanism to discover if you are allowed to perform action X should potentially not be build upon disco#info features

  502. lovetox

    i feel its really late to discover this now

  503. Zash

    flow: Makes sense.

  504. lovetox

    and there is no pressing issue to change what we currently do

  505. lovetox

    bad pattern is not a big motivation

  506. Maranda

    I'm not sure why presenting errors to users should be such a bad thing, beside most clients aren't using human readable conditions.

  507. Maranda

    I'm not sure why presenting errors to users should be such a bad thing, beside that most clients not using human readable conditions.

  508. flow

    Maranda, irregardless, it would be nice if we could do better, no?

  509. Maranda

    And checking everytime to prevent errors being thrown, doesn't sound very good practice wise.

  510. Maranda

    flow, doing better is nice but I don't think this is the bit that should be modified tbh.

  511. Maranda

    That's all.

  512. Maranda

    or s/that should/that needs to/

  513. Zash

    Someone invent authzcaps

  514. Zash

    Related wishlist: Separate pure machine-readable features from strings like identity names that can be customized and vary per client or deployment.

  515. sonny has left

  516. andrey.g has joined

  517. waqas has joined

  518. pep.

    MattJ, re RAI, to unsubscribe you must send an unavailable presence to the MUC service, so that's after the first unavailable presence to leave the MUC?

  519. pep.

    Or can I just declare an interest to any MUC even if I've never joined them at all

  520. alexis has left

  521. pep.

    Also maybe the NS can be updated to something not xmpp:prosody.im

  522. bear has left

  523. Zash

    pep.: Isn't that up to the editors?

  524. pep.

    the ns?

  525. pep.

    To update it?

  526. Zash

    Yeah. At least when a ProtoXEP is accepted as Experimental

  527. eta

    wait what's RAI

  528. Zash

    I might be using a private ns for my half-done proposal things

  529. pep.

    It's the first time during "editor career" that I come across a protoXEP that uses non-urn:xmpp ns

  530. pep.

    eta, it's at the PR stage for now, future protoXEP

  531. eta

    pep.: link?

  532. jonas’

    oh sexy, I should port my biboumi MR to that at some point

  533. pep.

    Zash, but I think you're right in that you're not technically allowed to use urn:xmpp as long as it's not a XEP. But I find it silly to not allow this in protoXEPs

  534. pep.

    eta, https://github.com/xsf/xeps/pull/925/files

  535. MattJ

    pep.: I don't understand your question about unavailable presence

  536. paul has left

  537. pep.

    I don't understand under what condition I can use RAI.

  538. pep.

    (or not use it)

  539. pep.

    And under what condition I can unset it

  540. paul has joined

  541. eta

    what's its intended usecase?

  542. MattJ

    The intended use case is stated in the intro and repeated elsewhere in the document

  543. MattJ

    E.g. requirements

  544. pep.

    MattJ, "A client may unsubscribe from activity indicators by sending an unavailable presence to the MUC service.", at this point the user is already not joined right?

  545. krauq has left

  546. MattJ

    Probably not

  547. krauq has joined

  548. pep.

    Can I also initiate rai when joined?

  549. MattJ

    Yes

  550. pep.

    What happens when I leave the room, does that also cancel rai?

  551. MattJ

    No

  552. Zash

    MUC service = bare host JID of the MUC?

  553. MattJ

    Yes

  554. pep.

    why?

  555. MattJ

    Why not?

  556. pep.

    because this has proved to cause weird issues in the past, and it works just fine addressing the room directly

  557. MattJ

    Which room?

  558. pep.

    a room

  559. Zash

    As punishment for whoever decided that room@host could be a MUC service?

  560. pep.

    any room

  561. pep.

    You want rai for multiple rooms just send that to multiple rooms?

  562. MattJ

    Read the requirements

  563. pep.

    What if I want rai for all rooms minus one

  564. MattJ

    There aren't many

  565. pep.

    I kinda think it's meh to assume nowadays that bare host is a muc component

  566. pep.

    Especially coming from prosody people :P

  567. Zash

    That's required by XEP-0045

  568. MattJ

    There are many things that are addressed to the MUC service in XEP-0045

  569. MattJ

    Also ad-hoc, etc.

  570. pep.

    ad-hoc on MUC is a thing in some implementation?

  571. pep.

    Ah biboumi maybe

  572. MattJ

    Of course, why not?

  573. pep.

    I've been waiting for that in prosody. Actually that's wrong, I've been waiting for ad-hoc on rooms

  574. MattJ

    Waiting? It can't be done now?

  575. pep.

    Anyway the unsubscribe thing is confusing

  576. MattJ

    I only added it at the last minute for completeness

  577. MattJ

    Anticipating that someone would say "but how do you unsubscribe?"

  578. Zash

    pep.: You'll have to wait for Prosodys ad-hoc to support commands on anything but host JIDs then.

  579. MattJ

    Now it's confusing to be able to unsubscribe :)

  580. Bronwen has joined

  581. Bronwen has left

  582. pep.

    Also "activity" doesn't seem very much defined

  583. MattJ

    "there are new messages in a room since the last time the user was joined there"

  584. pep.

    "A MUC may already send out-of-band notifications to users who are not currently joined if e.g. they are mentioned using &xep0372;" what's this then

  585. MattJ

    That seems a fine definition to me. Implementation specifics are indeed not defined, that's fairly intentional

  586. pep.

    I thought that was just another example of what it could be

  587. MattJ

    No?

  588. pep.

    So 372 is mentioned for no reason?

  589. MattJ

    It's an example

  590. pep.

    ok so it's all implementation defined :/

  591. MattJ

    I really think you're missing the point of this

  592. pep.

    I'm trying to understand why it's useful, even more so now that you're saying it's implementation defined

  593. pep.

    Don't get me wrong it's not just this XEP

  594. MattJ

    XEP-0372 is used for pushing notifications from a MUC to a user, about messages the MUC thinks the user should be notified about

  595. pep.

    (proto, whatever)

  596. MattJ

    But there are messages where the user is not mentioned

  597. pep.

    hmm, shortcuts? 372 is used to find out who to notify via some other mechanism

  598. MattJ

    and the user may still want to know whether there are any of those, or if the room has just been idle

  599. pep.

    I see

  600. pep.

    Makes a bit more sense

  601. MattJ

    "A MUC may already send out-of-band notifications to users who are not currently joined if e.g. they are mentioned using &xep0372;."

  602. MattJ

    "However a MUC typically won't forward other kinds of messages unless the user is joined."

  603. MattJ

    ^ Problem statement

  604. pep.

    Yeah.. we're all good at language all the time every time..

  605. pep.

    I'm still meh on the "implementation detail" thing, what is a "message" now :x

  606. MattJ

    Which "implementation detail" thing?

  607. marc has left

  608. paul has left

  609. marc has joined

  610. pep.

    "Implementation specifics are indeed not defined, that's fairly intentional"

  611. MattJ

    What would you define?

  612. MattJ

    Above what is already defined

  613. pep.

    what's a "message", or rather what's a "relevant" message, I guess would be more accurate here (something that other XEPs might be able to use)

  614. bear has joined

  615. pep.

    I guess you're not gonna send RIA for chatstates

  616. MattJ

    So you want it to list every possible kind of message in the XEP? Every combination of payloads?

  617. adiaholic_ has left

  618. adiaholic_ has joined

  619. pep.

    Well it's already being done in implementations having to know what a "relevant" message is, I don't see why not

  620. Zash

    Has <body> There, done.

  621. mukt2 has joined

  622. pep.

    :)

  623. MattJ

    The Prosody implementation depends on MAM on the MUC room, and it's considered activity if it gets archived

  624. Zash

    which boils down to "has <body>"

  625. MattJ

    So I could add a dependency on MAM, and basically spec this implementation

  626. pep.

    If there had to be such a XEP, I'd decouple it from MAM surely

  627. MattJ

    But I don't want to do that, because I think that's a very rigid/brittle approach that would be too limiting

  628. MattJ

    I think anyone who implements and deploys this would be able to make the right choice here

  629. MattJ

    If they don't, their implementation is screwed up and they'll see that

  630. MattJ

    But still, no harm done otherwise

  631. MattJ

    Specs matter for interoperability, this isn't an interop issue

  632. pep.

    Yes I think it is. I can't use the same client and expect the same behaviour if I use two different server implementations. Or maybe that's not called interop but it's as bad

  633. Zash

    Is this about to become another of those things like carbons, mam, csi etc where people disagree on how strict the rules should be?

  634. pep.

    It works in closed environments where you're only gonna use one implementation anyway

  635. pep.

    Zash, looks like the same problem to me

  636. Zash

    Someone™ should write down some guidance, either in xep-0226 or some new XEP.

  637. pep.

    Anyway.. afk rebooting server

  638. pep. has left

  639. paul has joined

  640. mukt2 has left

  641. pep. has joined

  642. werdan has left

  643. MattJ

    Zash: nice list of mostly XEPs written by me :)

  644. Zash has left

  645. MattJ

    Because yes, I do believe in defining what's necessary for interop and no more - at least in the early stages

  646. Zash has joined

  647. pdurbin has joined

  648. MattJ

    Things can always be tightened up later based on implementation experience, or requirements for specific deployments

  649. MattJ

    As long as the semantics are well definee

  650. MattJ

    As long as the semantics are well defined

  651. pep.

    well I don't think they are, well-defined semantics here would be defining "relevant" I'd say

  652. MattJ

    I also like to believe that most developers do have common sense

  653. pep.

    I don't recall off-hand if MAM provides guidelines at least? or carbons or..

  654. lovetox has left

  655. pep.

    carbons has some kind of rules right?

  656. pep.

    CSI?

  657. MattJ

    No, this is a protocol for telling the client to tell the user that something happened in the room

  658. pep.

    Anything?

  659. MattJ

    If the server thinks an affiliation change is important to that user, it should be allowed to send them a notification

  660. Nekit has left

  661. pep.

    fwiw, I firmly believe a user should be able to filter the kind of notification they get, so putting this in the hands of the server says this is already not for me

  662. MattJ

    Then feel free to not deploy it, but I'm deploying this next week

  663. MattJ

    There are early-stage plugins for Prosody, Openfire and Converse.js. It fills a need. If it doesn't fill your need, feel free to spec and implement something more complex that allows clients to specify filter rules.

  664. pdurbin has left

  665. MattJ

    I have a long list of XEPs that I intend to write and publish over the coming weeks... and this is by far the simplest and least controversial, so we're off to a good start :)

  666. Zash

    haha

  667. pep.

    :P

  668. arc has left

  669. arc has joined

  670. Shell has left

  671. adiaholic_ has left

  672. adiaholic_ has joined

  673. wurstsalat has left

  674. wurstsalat has joined

  675. Shell has joined

  676. Shell has left

  677. Shell has joined

  678. krauq has left

  679. mukt2 has joined

  680. Nekit has joined

  681. marc has left

  682. arc has left

  683. arc has joined

  684. mukt2 has left

  685. krauq has joined

  686. DebXWoody has left

  687. Daniel has left

  688. Daniel has joined

  689. Daniel has left

  690. calvin has joined

  691. marc has joined

  692. Marc has left

  693. Marc has joined

  694. Daniel has joined

  695. LNJ has left

  696. alexis has joined

  697. Marc has left

  698. Marc has joined

  699. Daniel has left

  700. moparisthebest has left

  701. krauq has left

  702. waqas has left

  703. waqas has joined

  704. krauq has joined

  705. Daniel has joined

  706. Dele has joined

  707. waqas has left

  708. waqas has joined

  709. calvin has left

  710. waqas has left

  711. waqas has joined

  712. xsf has joined

  713. waqas has left

  714. waqas has joined

  715. waqas has left

  716. waqas has joined

  717. emus has left

  718. waqas has left

  719. waqas has joined

  720. Jeybe has left

  721. Jeybe has joined

  722. waqas has left

  723. waqas has joined

  724. pdurbin has joined

  725. Jeybe has left

  726. waqas has left

  727. waqas has joined

  728. Jeybe has joined

  729. waqas has left

  730. waqas has joined

  731. waqas has left

  732. waqas has joined

  733. pdurbin has left

  734. waqas has left

  735. waqas has joined

  736. paul has left

  737. Jeybe has left

  738. waqas has left

  739. waqas has joined

  740. robertooo has left

  741. robertooo has joined

  742. paul has joined

  743. waqas has left

  744. waqas has joined

  745. Dele has left

  746. waqas has left

  747. waqas has joined

  748. emus has joined

  749. waqas has left

  750. waqas has joined

  751. waqas has left

  752. waqas has joined

  753. mukt2 has joined

  754. karoshi has left

  755. jubalh has joined

  756. goffi has left

  757. arc has left

  758. arc has joined

  759. Daniel has left

  760. emus has left

  761. emus has joined

  762. calvin has joined

  763. Daniel has joined

  764. alexis has left

  765. wurstsalat has left

  766. Seve has left

  767. alexis has joined

  768. calvin has left

  769. Shell has left

  770. Nekit has left

  771. mukt2 has left

  772. mukt2 has joined

  773. Daniel has left

  774. Shell has joined

  775. Daniel has joined

  776. andy has left

  777. jubalh has left

  778. Shell has left

  779. Shell has joined

  780. emus has left

  781. Daniel has left

  782. Daniel has joined

  783. mukt2 has left

  784. Marc has left

  785. arc has left

  786. arc has joined

  787. paul has left

  788. pdurbin has joined

  789. bear has left