XSF Discussion - 2020-04-13


  1. Maranda

    Hmm was WebSocket forgot on purpose? šŸ‘Øā€šŸ’»šŸ¤”

  2. emus

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

  3. emus

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

  4. Syndace

    what xD

  5. Syndace

    Yeah Maranda, stop speaking such unclear german!!!

  6. !XSF_Martin

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

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

  8. Maranda

    . . .

  9. !XSF_Martin

    šŸ˜‚

  10. Daniel

    Was are you taking about?

  11. !XSF_Martin

    Das should be clear now!

  12. flow

    Die Bart, Die

  13. emus

    Daniel: Misunderstanding, nevermind

  14. jonasā€™

    fun

  15. jonasā€™

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

  16. jonasā€™

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

  17. jonasā€™

    which is kind of meh if the feature isnā€™t offered on all accounts

  18. jonasā€™

    itā€™s in Draft. do we want to fix this?

  19. Daniel

    Yes

  20. jonasā€™

    alright, drafting a PR

  21. Daniel

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

  22. jonasā€™

    the yaks, they need shaving

  23. Zash

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

  24. Daniel

    For example

  25. Zash

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

  26. Zash

    Where's the XEP that descibes versioned namespaces?

  27. Zash

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

  28. Zash

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

  29. jonasā€™

    probably XEP-0001 or XEP-0143?

  30. jonasā€™

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

  31. Zash

    Lots of old things only advertise on the host JID

  32. Daniel

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

  33. Zash

    Agree. Historical things tho.

  34. jonasā€™

    neat, prosody only advertises it on the domain

  35. Zash

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

  36. jonasā€™

    no wait

  37. jonasā€™

    thatā€™s me not having it loaded in my e2etest prosody

  38. Daniel

    For most things I just check both in Conversations šŸ¤·ā€ā™‚ļø

  39. jonasā€™

    still not offered on the account though :(

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

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

  42. jonasā€™

    Zash, not complaining

  43. jonasā€™

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

  44. Zash

    Write a 3 line module for it :P

  45. jonasā€™

    Zash, that doesnā€™t solve the actual issue (broken XEP-0191)

  46. Zash

    Fun

  47. Maranda

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

  48. Maranda

    (for xep-0191)

  49. Maranda

    host disco#info together with the deprecated privacy lists

  50. flow

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

  51. Zash

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

  52. flow

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

  53. Zash

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

  54. jonasā€™

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

  55. jonasā€™

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

  56. 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"

  57. flow

    jonasā€™, I do not think that this is true

  58. Maranda

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

  59. Maranda

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

  60. flow

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

  61. Maranda

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

  62. flow

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

  63. flow

    because it is *everywhere* in xmpp

  64. flow

    and the discussion also appears every 2-3 years

  65. flow

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

  66. Zash

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

  67. Zash

    The Final Discussion

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

  69. 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)

  70. Maranda

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

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

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

  73. 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ā€¦

  74. Maranda

    ditto

  75. lovetox

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

  76. lovetox

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

  77. lovetox

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

  78. lovetox

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

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

  80. flow

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

  81. flow

    especially if it is returned depending on the entity which queries

  82. flow

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

  83. lovetox

    why?

  84. flow

    well caps for one

  85. lovetox

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

  86. lovetox

    1. we have no caps for host anyway

  87. flow

    I think it is in general a bad pattern

  88. lovetox

    2. for muc service also not

  89. flow

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

  90. lovetox

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

  91. lovetox

    we have to use whats there

  92. Zash

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

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

  94. Zash

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

  95. flow

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

  96. lovetox

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

  97. flow

    Zash, it is in most cases I think

  98. lovetox

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

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

  100. lovetox

    so we can live with it

  101. flow

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

  102. flow

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

  103. flow

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

  104. Zash

    But no caps for your own account features. :/

  105. flow

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

  106. Zash

    I mean as in disco#info

  107. 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)

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

  109. lovetox

    i feel its really late to discover this now

  110. Zash

    flow: Makes sense.

  111. lovetox

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

  112. lovetox

    bad pattern is not a big motivation

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

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

  115. flow

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

  116. Maranda

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

  117. Maranda

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

  118. Maranda

    That's all.

  119. Maranda

    or s/that should/that needs to/

  120. Zash

    Someone invent authzcaps

  121. Zash

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

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

  123. pep.

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

  124. pep.

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

  125. Zash

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

  126. pep.

    the ns?

  127. pep.

    To update it?

  128. Zash

    Yeah. At least when a ProtoXEP is accepted as Experimental

  129. eta

    wait what's RAI

  130. Zash

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

  131. pep.

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

  132. pep.

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

  133. eta

    pep.: link?

  134. jonasā€™

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

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

  136. pep.

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

  137. MattJ

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

  138. pep.

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

  139. pep.

    (or not use it)

  140. pep.

    And under what condition I can unset it

  141. eta

    what's its intended usecase?

  142. MattJ

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

  143. MattJ

    E.g. requirements

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

  145. MattJ

    Probably not

  146. pep.

    Can I also initiate rai when joined?

  147. MattJ

    Yes

  148. pep.

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

  149. MattJ

    No

  150. Zash

    MUC service = bare host JID of the MUC?

  151. MattJ

    Yes

  152. pep.

    why?

  153. MattJ

    Why not?

  154. pep.

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

  155. MattJ

    Which room?

  156. pep.

    a room

  157. Zash

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

  158. pep.

    any room

  159. pep.

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

  160. MattJ

    Read the requirements

  161. pep.

    What if I want rai for all rooms minus one

  162. MattJ

    There aren't many

  163. pep.

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

  164. pep.

    Especially coming from prosody people :P

  165. Zash

    That's required by XEP-0045

  166. MattJ

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

  167. MattJ

    Also ad-hoc, etc.

  168. pep.

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

  169. pep.

    Ah biboumi maybe

  170. MattJ

    Of course, why not?

  171. pep.

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

  172. MattJ

    Waiting? It can't be done now?

  173. pep.

    Anyway the unsubscribe thing is confusing

  174. MattJ

    I only added it at the last minute for completeness

  175. MattJ

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

  176. Zash

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

  177. MattJ

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

  178. pep.

    Also "activity" doesn't seem very much defined

  179. MattJ

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

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

  181. MattJ

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

  182. pep.

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

  183. MattJ

    No?

  184. pep.

    So 372 is mentioned for no reason?

  185. MattJ

    It's an example

  186. pep.

    ok so it's all implementation defined :/

  187. MattJ

    I really think you're missing the point of this

  188. pep.

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

  189. pep.

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

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

  191. pep.

    (proto, whatever)

  192. MattJ

    But there are messages where the user is not mentioned

  193. pep.

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

  194. MattJ

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

  195. pep.

    I see

  196. pep.

    Makes a bit more sense

  197. 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;."

  198. MattJ

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

  199. MattJ

    ^ Problem statement

  200. pep.

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

  201. pep.

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

  202. MattJ

    Which "implementation detail" thing?

  203. pep.

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

  204. MattJ

    What would you define?

  205. MattJ

    Above what is already defined

  206. 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)

  207. pep.

    I guess you're not gonna send RIA for chatstates

  208. MattJ

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

  209. pep.

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

  210. Zash

    Has <body> There, done.

  211. pep.

    :)

  212. MattJ

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

  213. Zash

    which boils down to "has <body>"

  214. MattJ

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

  215. pep.

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

  216. MattJ

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

  217. MattJ

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

  218. MattJ

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

  219. MattJ

    But still, no harm done otherwise

  220. MattJ

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

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

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

  223. pep.

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

  224. pep.

    Zash, looks like the same problem to me

  225. Zash

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

  226. pep.

    Anyway.. afk rebooting server

  227. MattJ

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

  228. MattJ

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

  229. MattJ

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

  230. MattJ

    As long as the semantics are well definee

  231. MattJ

    As long as the semantics are well defined

  232. pep.

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

  233. MattJ

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

  234. pep.

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

  235. pep.

    carbons has some kind of rules right?

  236. pep.

    CSI?

  237. MattJ

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

  238. pep.

    Anything?

  239. MattJ

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

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

  241. MattJ

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

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

  243. 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 :)

  244. Zash

    haha

  245. pep.

    :P