jdev - 2023-12-20

  1. moparisthebest

    That is roughly my gut reaction too, really cool, but kinda a privacy violation

  2. Guus

    I can't deny that there's a privacy aspect to this. I believe the potential impact to be minimal - not enough for me to shut down the application at least. I'm open to making modifications if people have specific concerns though.

  3. Guus

    I've updated the site with my contact info, so that people with concerns can reach out directly.

  4. Martin

    > Yeah, that's true. The page already shows if dwd is away from his computer... How?

  5. Guus

    Less connections to his node

  6. flow

    Guus, have you considered making 'domain' an attribute? is there a chance that we may have multiple domains over the same link the future (I think I saw some text about this, not sure if it's a XEP)

  7. flow

    and I wonder if the serverinfo couldn't optionally include timestamps, like 'established' and 'last-activity'

  8. flow

    + the privacy concerns mattj raised. I think I am ok with my domain showing up, but it is certainly something to consider

  9. flow

    maybe simply add a s2s flag that servers could set to annouce that they do not want to show up in such things

  10. flow

    (or maybe even make it an opt-in flag)

  11. Guus

    Flow, I'm not sure how using an attribute would allow for having multiple domains on a connection in a way that can't be done with a child-element? I moved the domain value from an attribute to a child element, as I vaguely recalled XML-based differences being a thing between an attribute value and a text-node value. I don't recall the details.

  12. Guus

    The timestamps are a nice idea. Practically, I think we'd not work with _live_ live data (as the amount of data from different sources is possibly to much to continuously update things). This makes the 'correctness' of these timestamps questionable in practice (at least in _my_ application, but that's not a reason to not allow for them. I designed the data format to be lean, as I was trying to reduce the data size. That's why it is quite minimal, as-is. Again, no reason to not allow for other things.

  13. Guus

    _If_ we're to address a privacy concern, then I much prefer an opt-in over an opt-out.

  14. flow

    Guus, what I tried to say is: if there can only be one domain for the element, then it's an point towards designing it as attribute

  15. Guus

    flow: ah, I thought you were trying to make a case for having multiple. Well, like I said, I vaguely recall something about it not being desirable to have JIDs in XML attributes. I might very well be wrong, but I thought I'd play it safe. I prefer to keep however we define a domain in the data format the same (we have two: one as a direct child of the root element, and one in `connection`).

  16. flow

    Guus, we use JIDs in attributes all the time: to= from= :)

  17. Guus

    The 'to' and 'from' attributes in every stanza are a great contr... yes that.

  18. Guus

    I obviously didn't think it trhough :D

  19. Guus

    Still, is there much benefit of having an attribute over a child element (or the other way around)?

  20. flow

    personally, I would have designed domain an attribute, ymmv

  21. flow

    well, if there can only be done, then you express this already on the XML level, which is an advantage imho

  22. flow

    well, if there can only be one, then you express this already on the XML level, which is an advantage imho

  23. flow

    well, if there can only be one, then you express this already on the XML level, which is an advantage

  24. flow

    of course, a faulty XML builder could still generate invalid XML where a 'domain' attribute appears twice on the same XML element

  25. flow

    however, some XML APIs may reject such a construct, and providing a hint towards the developer about an implementation error

  26. flow

    this wouldn't be the case when 'domain' is designed as element

  27. Guus

    You're not wrong - but I'm not seeing this as being very advantageous, to be honest. Im' sure that the same argument is true for many other XMPP data structures, where this could have been, but is not applied.

  28. flow

    even if it's not *very* advantageous, it's still an argument towards making it an attribute, whereas I can't think of an argument in favor of an element (but please provide one if you can think of one)

  29. Guus

    The existing implementation uses it. :)

  30. Kev

    If you ever think you might want to add additional information relevant to the value, element is the way to go. If you are entirely sure that you will never want to add more information, attribute is fine.

  31. flow

    and yes, XMPP's usage of XML is in *many* cases far from ideal. I guess that is becasue, developers do not think enough about how to design the protocol on the XML level, do not know enough about good design, and, of course, what is good design is sometimes subjective

  32. Kev

    So the basic stance that makes sense is always-an-element unless you have a very specific need that something must be an attribute :)

  33. Zash

    Data in text elements, metadata in attributes?

  34. Kev


  35. flow

    isn't the line between data and metadata blurry, especially in this case?

  36. MattJ

    The boundary between "data" and metadata is... what flow said :)

  37. Kev

    This discussion, for example, is metadata :)

  38. Guus

    That makes that remark a meta-metadata-remark? And this one... eh...

  39. MattJ

    Without having read the protoxep yet, I would model this as a series of connections, each having a 'to' domain and a 'from' domain, and any additional information (such as stanza count, features, etc.) would be as (potentially namespaced) child elements

  40. flow

    the list of <connection/> elements in Guus' XEP could be seen as a Map, which maps domain JIDs to their respective connection information. In this case, the doamin JID is the key, which makes it IMHO an ideal candidate to be designed as attribute

  41. Guus

    The current protoxep defines: ``` <serverinfo xmlns="urn:xmpp:serverinfo:0"> <domain>shakespeare.lit</domain> <federation> <connection type="incoming"> <domain>denmark.lit</domain> </connection> <connection type="both"> <domain>montague.net</domain> </connection> ```

  42. Guus

    (with optional extensions as child-elements of the `serverinfo` element)

  43. flow

    the list of <connection/> elements in Guus' XEP could be seen as a Map, which maps domain JIDs to their respective connection information. In this case, the domain JID is the key, which makes it IMHO an ideal candidate to be designed as attribute

  44. MattJ

    flow, be careful, there may be more than one connection to/from the same domain :)

  45. flow

    MattJ, fair point

  46. flow

    which raises the question if <connection/> should have the 'type' attribute removed and instead list the types as child element

  47. flow

    <connection domain=example.org><type><incoming/><outgoing/></type></connection>

  48. Guus

    That's what I called 'both' ;)

  49. flow

    ahh, I assumed both was bidi

  50. Guus

    oh, I didn't make that distinction

  51. flow

    good that we talked about it :)

  52. Guus


  53. Guus

    I actually had 'bidi' first, but dwd made me change it to 'both' :)

  54. Martin

    > Less connections to his node But s2s connections won't get closed if one goes afk so it's not a very reliable monitoring. Also new s2s might appear when someone messages him while he's AFK. So either I miss something or that's not a good way to determine availability.

  55. Guus

    > But s2s connections won't get closed Some servers close s2s connections after inactivity.

  56. Guus

    If a one-person xmpp domain has its sole user go offline, S2S connection count drops over time.

  57. Guus

    It's not guaranteed, and there are a number of reasons that this may _not_ happen - but still, it's _somewhat_ of an indicator clashing with privacy.

  58. MattJ

    Guus, if I understand what you're saying, I don't think you should combine connections with "both" like that

  59. MattJ

    or I'm not sure how you would correctly represent 2 incoming connections and 1 outgoing connection to the same domain

  60. Guus

    MattJ: no argument here.

  61. MattJ

    I think there should be one <connection> per actual (e.g. TCP) connection, and an attribute or child element that indicates bidi

  62. Guus

    That's sensible

  63. MattJ

    Maybe a bit of a tangent, maybe not, but I've been working on something for Prosody that provides an s2s overview that's *not* based on current connections: https://modules.prosody.im/mod_s2s_status

  64. MattJ

    The reason being, listing current connections only show successes, and it's hard to debug failures (incoming and outgoing)

  65. MattJ

    In this model it's less <connection> and more <remote-domain>, with live connections (and errors) being children of the remote domain

  66. Guus

    I do not dislike that. That'd even allow you to express federation with a remote domain, without iterating over specific connections. If all that you want is to know if there's federation...

  67. MattJ

    Yes, it would be a potential improvement with regards to privacy (not a total fix, though)

  68. Guus

    (well, unless the absence of a connection is relevant, eg, if there's an error)

  69. MattJ

    IIRC mod_s2s_status stores the last N connection attempts, and if all failed then the whole thing is considered in an error status

  70. MattJ

    But it's all a WIP and not really being used for anything yet (the UI is still half-baked on my laptop)

  71. flow

    Yes, having a <domain/> element wrapping all connections (sucessful or not) makes a lot of sense

  72. flow

    MattJ, when do you have more than one incoming(/outgoing) connection for a domain? if one is down and the other one is about to be established?

  73. MattJ

    It can happen under normal circumstances, I think ejabberd does (or at least used to) intentionally open multiple connections to a remote domain

  74. MattJ

    It's also of course common between domain pairs in clustered deployments

  75. flow

    I see

  76. MattJ

    There's nothing anywhere that says there should only be one connection per domain pair, even though that's the norm

  77. MattJ

    Prosody will never open multiple connections to a domain, but it accepts multiple incoming

  78. Zash

    You should see the number of xonnections from servers with frequently rotating IPs due to DHCP or somesuch

  79. Zash

    You should see the number of connections from servers with frequently rotating IPs due to DHCP or somesuch

  80. MattJ

    and by "connections", I'm excluding brief moments like you were talking about, such as the temporary connection for verifying dialback, etc.

  81. Guus

    Trying to capture the discussion above in a new example, that _also_ allows for a local server to service more than one local domain: ``` <serverinfo xmlns="urn:xmpp:serverinfo:0"> <domain domainname="shakespeare.lit"> <federation> <peer domainname='denmark.li'> <connection type="incoming"/> <connection type="outgoing"/> </peer> <peer domainname='montague.net'> <domain></domain> <connection type="bidi"/> </peer> </federation </domain> </serverinfo> ```

  82. Guus

    Oh, I missed a 'domain' child element in the second peer. That should be removed.

  83. MattJ

    Looking good

  84. jonas’

    regarding the privacy consideration: how about an <other-peers count=".."/> element or so, which allows servers to summarize the number of peers without naming domains?

  85. jonas’

    or maybe an other-incoming=".." other-outgoing=".." attribute pair on <federation/>

  86. flow

    Guus, I wonder if it makes sense to design different elements for the connection types, as different connection types may have differnt metadata kinds associated

  87. flow

    nit: I would probably s/peer/remote-domain/, then you could also s/domainname/name/g

  88. Guus

    jonas’ ... maybe, sure. I'd like to think this over more (and gather more feedback)

  89. Guus

    flow: possible, but I'm not sure if it's desirable to add more details to a connection, even if we technically can.

  90. Guus

    maybe just use 'domain' instead of 'peer'?

  91. flow

    sure, but you know yourself that once a protocol is implemented its more-or-less locked in

  92. flow

    Guus, there is already an outer <domain/> element in the same namespace

  93. flow

    which has different semantics

  94. flow

    I am actually not sure where the outer <domain/> element comes from. the same server annoucing connections of all its vhosts?

  95. Guus


  96. flow

    ok, then the outer element should stay <domain/> and <peer/> should either stay or become <remote-domain/>

  97. flow

    and going back to the connection types: Instead of <connection type=incoming/> I would consider <incoming-connection/> (and so on). Just in case. Even though, that's only a minor concern

  98. Guus

    I don't like that. They're all connections, that I'd like to be able to iterate over in one go.

  99. Guus

    ``` <serverinfo xmlns="urn:xmpp:serverinfo:0"> <domain name="shakespeare.lit"> <federation> <remote-domain name='denmark.li'> <connection type="incoming"/> <connection type="outgoing"/> </remote-domain> <remote-domain name='montague.net'> <connection type="bidi"/> </remote-domain> </federation> </domain> </serverinfo> ```

  100. flow

    I don't see how that changes anything regarding iteration, but your call

  101. MattJ

    I considered that too, but I think <connection> is probably fine

  102. MattJ

    after <incoming-connection> and <outgoing-connection> you then have <bidi-connection> and who knows what else comes along :)

  103. flow

    until you want to express in the schema that one connection kind has different requirements than others

  104. jonas’

    smells like premature complexity tom e

  105. MattJ

    I don't think we need to express that in the schema necessarily

  106. jonas’

    smells like premature complexity to me

  107. flow

    sure, I don't have an example for that, and it maybe never happens that we run into this case, but you never now

  108. flow

    I fail to see how the complexity of <connection type=foo/> is much different from <foo-connection/>

  109. MattJ

    At least in Prosody you can iterate over child tags of a specific type

  110. MattJ

    You can't iterate over a set of types at once

  111. jonas’

    similarly, in aioxmpp, you'd need separate struct types for these

  112. MattJ

    I think it's a pretty common API

  113. jonas’

    and you couldn't have generic code which listed connections by their (machine readable) @type attribute

  114. Guus

    any thoughts of using 'peer' vs 'remote-domain' ? I dislike that dash...

  115. Guus

    (I also dislike 'remoteDomain' just as much as that dash ;) )

  116. jonas’

    no strong opinion

  117. jonas’

    (slight tendency toward remote-domain; I like skewers)

  118. Guus

    in XSD, how does one define an extension point? Basically, 'add any element in another namespace here if you want' ?

  119. jonas’

    I think that's implied in XMPP

  120. flow

    Guus, kebab case is very common for XML

  121. flow

    Guus, we assume that every element can be extended

  122. Guus

    Nowadays, Wham's Last Chrismas is very common too. I still don't like it.

  123. Guus


  124. jonas’

    Guus, that's low down :P

  125. Guus

    (Also, I'm grumpy because I'm already out in this years Whamageddon.

  126. jonas’

    I am not!

  127. flow

    I think it's also common in XEPs, but I haven't researched it. having a common style in XEPs (which hopefully would be kebap case) would be very nice

  128. Guus

    heh, we're not even consistently using the same term for ... pubsub... pub/sub... pub-sub... PubSub... publish/subscribe.

  129. Kev


  130. flow

    consistency is always hard to achieve, especially since we don't explicitly review for it and have no guidelines

  131. Guus

    Talking with Kev sometimes has the vibe of the Matrix movies. He's talking all weird numbers and glyphs, but all I see is blonde, brunette, redhead... ;)

  132. Guus

    I've pushed the changes we discussed to the PR of the inbox.

  133. flow

    Guus, thanks for working on that :)

  134. flow

    Guus, maybe specify if you believe that the value of type should be strictly from the set of 'incoming', 'outgoing' or 'bidi'. Or, if you envision that this attribute may hold a different value in the future

  135. flow

    if it should be strictly from the set of those three values, then it could be required by the scheme definition

  136. flow

    and should probably be specified using RFC keywords

  137. MattJ

    Thinking aloud, should it be possible to distinguish an incoming connection that has enabled bidi vs an outgoing connection that has enabled bidi?

  138. flow

    can't probably hurt to be able to express that

  139. flow

    and, what just occured to me, what about TLS information. that would be really nice to have it

  140. flow

    although it could be added later to the xep

  141. flow

    but having the information if the connection was TLS secured, and, if so, which certificates where used, would help with certificate transparency

  142. Guus

    the connection type is now an xsd-based enum (or at least, that's what I tried)

  143. Guus

    For now, I'm not planning to go much deeper. I'd first like to have a working solution, rather than deep-diving in what I fear will be a never-ending list of additional details.

  144. Guus

    I have updated the implementation of https://xmppnetwork.goodbytes.im/ to accept both the old data format, as the one that's now in the protoXEP. Apart from a unit test, I've not tested the new format in the wild (as that would require updating the Openfire plugin, for which I now have no time left). If someone else could try this, that'd be helpful.

  145. MattJ

    I'm not likely to implement it without some solution to the privacy thing. Maybe a way for domains to opt in, or some other way of detecting a public server.

  146. Guus

    Detect the availability of something like in-band regisration maybe?

  147. jonas’

    snikket servers offer IBR, if i'm not mistaken

  148. jonas’

    and they're the opposite of public.

  149. Guus

    jonas’, what's the policy with the s.j.n. crawler? Does that only include rooms from MUC servicds that have been explicitly opted-in?

  150. jonas’

    Guus, s.j.n takes anything it sees, but only lists rooms which have been marked as public

  151. jonas’

    (there are a handful of domains which actually contacted me for an opt-out from the scanner tho)

  152. jonas’

    so to have your domain appear publicly on s.j.n, it requires a MUC on that domain which has been set as public via its configuration form

  153. jonas’

    there have been some arguments that the text commonly shown next to that checkbox is not clear enough about the impact and there should be a more explicit opt-in to that

  154. jonas’

    but nobody has done that work so far and I'm on the fence about that

  155. jonas’

    still, as it stands, s.j.n won't publish a domain unless someone who has been granted permission to create MUCs on that domain chooses (or has a buggy client choose for them) to make a MUC public

  156. Martin

    > snikket servers offer IBR, if i'm not mistaken Indeed, my prosody with 'great invitations' also has IBR enabled, but it only works with invitations. I'd opt in for this thingy though.

  157. jonas’

    which is in contrast to this federation map thing, I think, and I think that deserves some explicit opt-in indeed.

  158. jonas’

    which is in contrast to this federation map thing, I think, and I think that deserves some kind of explicit opt-in indeed.

  159. Guus

    (I'm unsure if Martin expressed the desire to have an opt-in feature, or a desire to have the feature enabled if they had to opt-in)

  160. Guus

    Would replacing the remote-domain's required 'name' attribute with either a 'name' or a 'unique-id' attribute be an acceptable solution? If we define the one-way function to calculate the unique-id, we'd still be able to create a network graph (which is basically my drive to publish this XEP). It doesn't rule out brute-forcing a the limited-number of domain names, I guess...

  161. Martin

    Not sure I understand. I think it should be opt-in and I would/will opt-in.

  162. Guus


  163. singpolyma

    Domains are hardly secrets, but some people do get spooked seeing lists of things these days. The space of possible domains is basically infinite so just hash is probably enough but could do argon with a fixed salt if concerned about being "too easy"?

  164. Guus

    (or we could mandate the uniqueId value, and make the name optional)

  165. MattJ

    If a domain could opt in, it could opt in to "public", "obscured" or "private", where "obscured" means the domain is hashed

  166. MattJ

    Like, if zash.se chose to be obscured, it wouldn't be hard for me to test whether he and dwd are contacts (your current demo shows that they are)

  167. Guus

    I'm offering this as an alternative to opting in, as I'd like to be able to represent nodes (even if they have no label) in a graph.

  168. MattJ

    I'm saying there should definitely be a way to opt out

  169. MattJ

    and that does mean the network graph will be incomplete (though there was a suggestion earlier to show something like "and N others")

  170. singpolyma

    If i give you my s2s list I'd basically be telling you how many customers I have and to an approximation who they are

  171. singpolyma

    I guess MattJ is right too in an ideal network this is full social graph data. So even hashed it's easy to trace

  172. Guus

    I'm thinking that the 'opting' should be performed at the server that provides a node that publishes serverinfo in pubsub (as opposed to the xmppnetwork website, which could _also_ have that, but that'd be additional to anything else). With that, would a strategy to generate a to-be-published item be sufficient, where: 1. By default, connections have a unique-id only 2. connections have a name if the remote domain also supports this XEP / has the same pubsub node) 3. connections are not included at all if the remote domain ... has some kind of disco/info flag, opting out.

  173. MattJ

    If by "unique id" you mean hash, and someone is publishing a hash of my domain when I connect to them, I would prefer if that had to be explicitly opted into

  174. Guus

    singpolyma, you'd not give me your list if you do not want to, _but_ the list might be inferred from other servers connecting to the same remote domains as yours

  175. MattJ

    I'm not going to claim it's not within your right to publish information about who is connecting to you, but I think this should be a part of the protocol

  176. MattJ

    As I said, this is not a new idea, but a big reason nobody actually deploys it is because of the information leaks

  177. MattJ

    If you want people to deploy it, having robust privacy considerations is essential

  178. MattJ

    That specifically means being safe by default, so not revealing anything that someone didn't choose to reveal

  179. Guus

    I suspect that a larger reason why nobody deploys it is because of more technical reasons - things outdate quickly if they're not maintained. :)

  180. Guus

    but, I hear you.

  181. Kev

    I think it's not unreasonable to assume similar privacy implications for S2S lists as rosters.

  182. Guus

    I'm not sure if I fully appreciate the privacy impact being that large, but there is at least _some_.

  183. Kev

    As they're equivalent in the degenerate case.

  184. singpolyma

    You say degenerate, I say ideal 😉

  185. Guus

    isn't almost everything, in a degenerate case?

  186. Kev

    Isn't almost everything equivalent to a roster? No, I don't think so :)

  187. Guus

    How far do you degenerate a roster when it stops being a roster?

  188. Kev

    It's not the roster being degenerate in this case, it's the number of active users on a server.

  189. Guus

    but, as a practical change: would simply _removing_ the 'name' (and other data) be sufficient? you'd have a bunch of 'remote-peer' elements, that could possibly be drawn as individual lines, but not connect

  190. Guus

    basically the same as the suggested 'count' solution, but without adding a new element.

  191. singpolyma

    Stops really being a graph in that case, but yeah

  192. MattJ

    I think that's a protocol/UI technicality, but sure

  193. Guus

    singpolyma it stops really being a graph by an opt-in too :)

  194. MattJ

    No, you just show the part of the graph that has opted into being published

  195. MattJ

    Which will probably be a chunk of it - ultimately all the public servers should at least opt in

  196. Guus

    oh, sorry, I mean to drop the name of remote-domains _only when the remote domain does not support the same XEP_.

  197. Guus

    (which probably will be the majority of them)

  198. MattJ

    Sure, it will reduce your current graph somewhat, but I still think it's wrong to publish that Zash is contacts with dwd without further consideration.

  199. MattJ

    We know both Zash and dwd in this community, it's hardly a surprise they communicate with each other, but that's not something that we should expect to be okay for people outside this chatroom

  200. Guus

    Doesn't my suggestion offer that improvement?

  201. singpolyma

    Yes i think supporting the xep yourself is a fair opt in

  202. MattJ

    Yeah, sure

  203. singpolyma

    It also solves my count of customers concern because presumably most customers would not opt in

  204. Kev

    Just to check 'supporting' in this case means "running server software that implements it, and enabling the opt-in configuration'?

  205. singpolyma

    It does make the graph a lot less interesting since you'll probably just get a dozen big nodes all connected to each other,, but that's by design I guess

  206. Guus

    'supporting the XEP' currently means: have a pubsub node with a well-known name published. I didn't imagine that that went without comment for as long as it is doing.

  207. singpolyma

    Published where?

  208. Guus

    as a first-level leaf node by the name 'serverinfo' on a pubsub service on your domain.

  209. Kev

    Could a normal user not create that if they can publish arbitrary nodes?

  210. Guus

    Like I said, I didn't imagine that this went without comment for as long as it ... did.

  211. singpolyma

    Guus: just any pubsub service discoverable from your domain?

  212. singpolyma

    I'd think having it as effectively pep on the domain itself is clearer and safer

  213. Guus

    singpolyma: that's how I've worded it now (probably should exclude PEP...). The implementation hard-codes 'pubsub.<domain>'

  214. MattJ

    While you're in the XEP, maybe sneak in active user counts like we have in the existing nodeinfo stuff

  215. MattJ

    https://vvvvvvaria.org:5281/.well-known/x-nodeinfo2 is an example, and it is scraped by this frontend: https://the-federation.info/protocol/20

  216. Guus

    Argh, words are hard. Can someone offer a better alternative to this text? > When multiple domains publish their connections to named remote domains, an information leak occurs: by collecting these public statistics, behavioral data of those remote domains can be deduced. To prevent undesired privacy-sensitive information leaks, a domain MUST only publish the name of a remote domain when that remote domain supports this XEP.

  217. jonas’

    I'd reword the last sentence to: > To prevent undesired privacy-sensitive information leaks, a domain MUST NOT publish the name of a remote domain, unless that domain advertises support for this XEP.

  218. Guus


  219. Guus

    I pushed a change for this privacy concern to the protoxep in the inbox.

  220. Guus

    todo: fix the discovery mechanism Adding additional data is a longer-term goal for now :)

  221. MattJ

    If I implement it, I'm going to include it in some namespace if it's not defined :)

  222. Guus

    The xep explicitly allows for that. I'm not even saying I don't want it in this XEP, but it's lower on my priority list of things to fix.

  223. Guus

    Eh, what's a good service discovery mechanism here? A feature flag? Something that explicitly points at a pub-sub node name?

  224. singpolyma

    I guess you want to use a subdomain pubsub service so that servers don't have to deploy any code?

  225. singpolyma

    A service disco form that points at pubsub service and node name could work and be insertable with an existing midule in prosody at least

  226. singpolyma

    A service disco form that points at pubsub service and node name could work and be insertable with an existing module in prosody at least

  227. Guus

    servers will have to 'deploy code' to iterate over things to collect data to-be-published anyway?

  228. singpolyma

    Well in that case why not make it a node right on the domain?

  229. Guus

    I'm not sure if we're talking about the same thing. I lost you. :)

  230. singpolyma

    Instead of using pubsub. subdomain or similar and disco

  231. Guus

    you'd still want pub-sub functionality, which I guess makes it a node under a pub-sub service/

  232. singpolyma

    Every jid can be a pubsub service. This is the gift pep brought us

  233. Guus

    I'm not sure if I'm comfortable having a PEP service for the domain-JID itself. I wonder what that means, implementation-wise.

  234. MattJ

    I'm inclined to agree that it's probably a can of worms

  235. MattJ

    For example, according to XEP-0060 the nodes would then appear in disco#items queries on the bare domain, and I guarantee that will break clients :)

  236. MattJ

    There are various improvements I'd like to make to disco, but that's another thread for another day

  237. singpolyma

    Is pep contrained by that disco items requirement? I guess it probably is

  238. Guus

    So, a feature and a form pointing at a pubsub service and nodeId, on the disco#info response of the domain? Wasn'ts there somethign about a limited amount of forms in there?

  239. MattJ

    Heh, yeah, we were discussing that the other day

  240. MattJ

    The XEP says there should only be one form defined by the XSF per identity

  241. Guus


  242. Guus

    > Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity).

  243. Guus

    per https://xmpp.org/extensions/xep-0128.html#impl

  244. MattJ

    and we kind of already have one for im/server, and it's called "serverinfo", funnily enough)

  245. MattJ

    Note that I said "one form defined by the XSF"

  246. Guus

    oh, right

  247. MattJ

    It's two because the other can be an application-specific form

  248. Guus

    What's a better approach than having a feature added, and depending on a hard-coded pubsub service and node ID?

  249. MattJ

    But at least one person thinks that limitation should be removed from the XEP

  250. Guus

    even if we do, it currently is in - and therefor will be in implementations.

  251. MattJ

    You could extend the existing serverinfo form with a link to a pubsub node

  252. MattJ


  253. Guus

    does the definition in https://xmpp.org/registrar/formtypes.html#http:--jabber.org-network-serverinfo track with the example in https://xmpp.org/extensions/xep-0128.html#examples-server ?

  254. MattJ

    The example is an example

  255. Guus

    but confusingly uses the same form-type identifier.

  256. MattJ

    Confusing, I agree

  257. MattJ

    You can put whatever you want in a data form. The choices are: 1) register the form field name in the XSF's registry, 2) use a prefixed name (`{urn:example:foo}your-name`), 3) neither of the above and accept there might be conflicts (not recommended)

  258. MattJ

    Pretty much all the XEPs have examples with unregistered form fields

  259. MattJ

    MUC is the best, there are some gems that are only documented in example form fields

  260. Guus

    > In general, the XMPP Standards Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. where's the definition of what category+type goes with what identity?

  261. Guus

    I mean, if I choose to add the pubsub coordinates to an existing form to get out under the limit of having just one XSF-defined form per identity... how do you know that the form that I'm using is an applicable one?

  262. Guus

    Implementation wise, piggybacking on a form that may or may not be included by other code is probably a recipe for disaster.

  263. MattJ

    I definitely disagree

  264. MattJ

    Firstly, the form is about providing a machine-readable way to present server information, and that's what this is. So it fits logically.

  265. MattJ

    Secondly, data forms are meant for adding new fields, that's why serverinfo is not just an XML element with a defined schema.

  266. MattJ

    There are multiple ways to extend data forms, as I listed earlier

  267. MattJ

    We've been doing it since forever

  268. Guus

    Oh, I do not disagree with the data format. I do not like having more than one bit of implementation adding to that one form. At least in our implementation, I fully expect some bit of code to provide 'the entire' form, not expecting others to add to that.

  269. MattJ

    Ah, I see. I don't think that's a concern of the XEP, it's a concern of the implementation.

  270. MattJ

    The alternative is to add multiple forms, which is explicitly discouraged by the XEP, but probably also widely supported.

  271. Guus

    True, but enough of a blocker for me to dislike it intensely.

  272. MattJ

    I find that a surprise. You have something that renders a serverinfo form, but you can't add server information to it?

  273. Guus

    I don't think we have a serverinfo form at all?

  274. Guus

    we have that list of contact accounts, if that's in the same form, but that's the entirity of the form I think

  275. MattJ

    The contact addresses are in the serverinfo form, yes

  276. MattJ

    XEP-0157 also has a status page URL, but that's not in the registry link I sent earlier (our registry has been unmaintained for a while, but that's gradually getting fixed)

  277. Guus

    I think in our case, that _is_ the form.

  278. MattJ

    Sounds similar to Prosody

  279. Guus

    but anyway, managing one form from more than one provider is not ideal for us.

  280. MattJ

    So make your one provider support multiple things

  281. MattJ

    Otherwise it's weird

  282. MattJ

    Like implementing disco#items but only supporting listing of MUC domains and nothing else

  283. Guus

    I think we're miscommunicating. We do support having multiple things (items, forms), provided by distinct providers. We cannot have multiple providers provide the same form (it'll presumably overwrite an earlier form, or cause two forms by the same ID to be added)

  284. MattJ

    and I'm saying that you seem to have a "server info form" provider that only supports contact addresses ?

  285. MattJ

    and that this is a limitation that doesn't match the way the protocol is supposed to be

  286. MattJ

    The form is not only for contact addresses

  287. Guus

    most providers are optional - so I can't depend on that being there.

  288. Guus

    I'm happy to accept that this is an implementation thing - but it's not something that I can easily change.

  289. MattJ

    I don't think designing the protocol around Openfire implementation quirks is ideal

  290. MattJ

    Prosody currently also only publishes the serverinfo form from the plugin that provides contact addresses, but that's something I already wanted to address

  291. MattJ

    Like, do you only have one piece of code that is able to add disco#info features?

  292. Guus

    So far, we've been able to chug along nicely without us even noticing that this is an issue. That points at this mechanism not being used all that much, at least not by Openfire, which may indicate that there are alternative solutions for the issue at hand.

  293. MattJ

    There aren't, this is how you publish metadata about a server. It's just that until now the only things people cared much about were the contact addresses and status page URLs

  294. Guus

    In Openfire, everything that implements a set of interfaces (DiscoInfoProvider, DiscoItemProvider) can provide data, that's then aggregated.

  295. MattJ

    The alternative is iterating disco#items and either a feature on the pubsub server you want to serve this data on or just peeking for the node (which I don't think is a good idea)

  296. Guus

    I guess we can ... merge things on aggregation?

  297. MattJ

    For example, with the current approach, if someone has a pubsub.example.com that is writable by users, then any user can create this node and publish fake info there.

  298. MattJ

    If the server explicitly tells you that it publishes this info and where, that's no longer a problem

  299. Guus

    Yeah, definitely not good. So, a disco/info feature would flag that some admin added support. But you'd still not want the coordinates of the pubsub node hard-coded.

  300. Neustradamus

    "ProtoXEP: PubSub Server Information" ticket created for: - ejabberd: https://github.com/processone/ejabberd/issues/4125 - Tigase: https://github.com/tigase/tigase-server/issues/215 - Metronome IM: https://github.com/maranda/metronome/issues/555

  301. Neustradamus

    "ProtoXEP: PubSub Server Information" ticket created for: - ejabberd: https://github.com/processone/ejabberd/issues/4125 - Metronome IM: https://github.com/maranda/metronome/issues/555 - Prosody IM: https://issues.prosody.im/1835 - Tigase: https://github.com/tigase/tigase-server/issues/215

  302. pep.

    "flow> maybe simply add a s2s flag that servers could set to annouce that they do not want to show up in such things" yeah no please don't force people to opt-in to opt-out again

  303. Guus

    I've modified https://github.com/xsf/xeps/pull/1312 to now address the privacy concerns that were discussed here today, as well as service discovery.

  304. Guus

    MattJ, even if I didn't add the additional stats yet, I'd love your review of this, if only to confirm that this is in-line with your perspective of what we discussed.

  305. Zash

    I had a thing once where you could query and get s2s details like TLS cipher and such, very useful back in the early days of mandatory TLS. Bitrot got to it bad tho.

  306. Zash

    Would be neat to have global stats on actually used TLS versions, ciphers and other features ;)

  307. Guus

    I'm happy to slap on all kind of additional data, but first want to get the basics right. I'm bad at keeping track of many different change-requests at the same time, which is why I prefer for the most important stuff to go in first.

  308. MattJ

    LGTM! Minor typo: s/supporting for/support for/

  309. pep.

    Happy 1312th PR!

  310. MattJ


  311. Zash

    https://scp-wiki.wikidot.com/scp-1312 ?

  312. Guus

    Thanks MattJ, typo fixed.

  313. moparisthebest

    > Would be neat to have global stats on actually used TLS versions, ciphers and other features ;) transports in use would be interesting now