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