XSF Discussion - 2020-06-23


  1. edhelas

    https://blog.riot.im/the-world-is-changing/

  2. MattJ

    The most interesting part of that is that they are merging the brand of Riot (open-source client) with the brand of their commercial stuff

  3. Zash

    How's this of relevance to XMPP?

  4. pep.

    > We’re in a terrible position if someone forks Riot using the same or similar name and logo, makes some dubious changes, and we can’t take action to persuade the app stores to remove it. "boohoo I can't sue people for reusing my name".

  5. Ge0rG

    > a certain large games company that has consistently blocked us from being able to trademark Riot or even Riot.im what an asshole move, just blocking out somebody who came after you and wanted to make use of your name!

  6. pep.

    yeah that's awful

  7. Ge0rG

    funny background story: that certain large games company used XMPP for match-making in their well-known online game, and there once was a third-party closed-source in-game-chat app, clone of a FLOSS/GPL xmpp client, that included artwork from the game. A certain FLOSS justice warrior inquired both the original xmpp client developers and riot to Do Something Because of Copyright Violation, and both parties just didn't care.

  8. Zash

    https://technology.riotgames.com/search?search=xmpp :)

  9. pep.

    Isn't that Riot Games contributing to XMPP by preventing Matrix Riot from being a thing? :P

  10. Ge0rG

    pep.: yeah, the irony is overwhelming

  11. debacle

    Ge0rG What does "match-making" mean?

  12. Zash

    Finding other people to play with?

  13. debacle

    Zash I see. The only computer game I play once in a while is https://screenshots.debian.net/package/aisleriot - that's how social I am!

  14. lovetox

    do we have diff service between 2 xep versions?

  15. lovetox

    or how are you guys doing that

  16. Neustradamus

    lovetox: https://github.com/xsf/xmpp.org/issues/412 :)

  17. Neustradamus

    lovetox: You can comment on it, add an emoji...

  18. Neustradamus

    But for the moment: http://www.aptest.com/standards/htmldiff/htmldiff.pl?oldfile=https://xmpp.org/extensions/attic/xep-XXXX-X.X.X.html&newfile=https://xmpp.org/extensions/attic/xep-XXXX-X.X.X.html

  19. lovetox

    thanks Neustradamus

  20. lovetox

    flow, care to elaborate on your change in 0373 regarding notification-only nodes

  21. lovetox

    why is the metadata node now payload less

  22. lovetox

    as i see it this would prevent me from knowing if keys have changed

  23. jonas’

    lovetox, XEP diffs may be viable with gitlab-based infrastructure (or when someone smarter than me figures out all the equivalents in github)

  24. lovetox

    ok jonas’ nice, you have all my support on your gitlab endeavor !

  25. lovetox

    tell me if i should bribe someone

  26. jonas’

    note the "may" in the sentence ;)

  27. Zash

    I've got stuff based on conversion to markdown before diffing, but that's of course unusable to anyone else.

  28. jonas’

    lovetox, another way would be to spin up a service which does html diffs on demand on the server which also runs xmpp.net; it should have some resources left

  29. jonas’

    lovetox, that would "just" need someone who puts such a service in a docker container d)

  30. jonas’

    lovetox, that would "just" need someone who puts such a service in a docker container :)

  31. moparisthebest

    * a wild awk user appears to challenge jonas’ mastery of doing things that shouldn't be done with command line tools https://github.com/rethab/awk-jvm *

  32. jonas’

    *twitch*

  33. jonas’

    moparisthebest, it’s your fault if everything stalls now while I create a similar insanity in sed

  34. moparisthebest rubs hands evilly

  35. jonas’

    though for this complexity, I’d probably first have to complete my assembly-to-sed compiler

  36. DebXWoody

    :-D A="xep-0045-1.29";B="xep-0045-1.30"; wget https://xmpp.org/extensions/attic/${A}.html; wget https://xmpp.org/extensions/attic/${B}.html; w3m ${A}.html>${A}.txt;w3m ${B}.html>${B}.txt; vimdiff ${A}.txt ${B}.txt

  37. DebXWoody

    It would be nice to have the current version in the same style like the attic files.

  38. jonas’

    DebXWoody, I don’t follow, what do you mean regarding the style?

  39. pep.

    DebXWoody, with a version appended?

  40. pep.

    That would require proposed changed to be in the attic though, to answer lovetox's comment

  41. DebXWoody

    jonas’, The files in https://xmpp.org/extensions/attic looks different like the https://xmpp.org/extensions/ (e.g. table of content). The diff of current and the attic html file is not working well

  42. pep.

    ah

  43. Zash

    This be why you'd wanna compare the source XML, not the output HTML

  44. flow

    lovetox, the node id will tell you if you have the latest item of that node

  45. jonas’

    DebXWoody, ah, that’s true, but only for older XEPs

  46. jonas’

    *older revisions

  47. jonas’

    unfortunately, we have no technically feasible way to re-render the old versions

  48. jonas’

    (in some cases, I don’t think we even have the XML of the old versions anymore, since that might be pre-git)

  49. lovetox

    flow what ID?

  50. flow

    err item id

  51. jonas’

    lovetox, pubsub item id

  52. lovetox

    you dont mandate anything about the ID

  53. Zash

    "current" \o/

  54. lovetox

    the id could be "current" for all notifications

  55. flow

    IIRC xep60 does

  56. lovetox

    no it doesnt

  57. flow

    I think it does

  58. Zash

    > The publishing entity SHOULD set the PubSub item ID to the time the item is published encoded as DateTime format specified in XEP-0082.

  59. Zash

    That?

  60. flow

    no xep60

  61. lovetox

    Zash thats not the node we are talking about

  62. flow

    something along the lines that if no item id is set, then the service should create a unique one

  63. lovetox

    flow why do you think there is no item id set

  64. Zash

    Where?

  65. lovetox

    does your XEP mandate that it is imperativ that NO item id is iset

  66. lovetox

    no?

  67. lovetox

    so then this whole approach just does not work

  68. jonas’

    flow, what lovetox says is relevant, since PEP stuff typically will use id='current'

  69. jonas’

    since that has numerous advantages

  70. flow

    happy to clarify that current shouldn't be use for the metadata node

  71. flow

    happy to clarify that current shouldn't be used for the metadata node

  72. flow

    but I wasn't aware that PEP mandates the use of 'current' as item id in the spec

  73. lovetox

    hm would not really make me happy, did you think about what that means for clients now?

  74. lovetox

    this means i have to have a database of all contacts and the last item id i saw from them

  75. Zash

    https://xmpp.org/extensions/xep-0060.html > if [the] publish request did not include [an] item ID, pubsub service MUST generate item ID

  76. lovetox

    just to know if something changed

  77. flow

    lovetox, you don't have to, you can also fetch the keys from all contacts everytime you connect

  78. Zash

    Huh but it varies

  79. Zash

    https://xmpp.org/extensions/xep-0060.html#table-4

  80. jonas’

    I swear this table wasn’t there the last time I read xep60

  81. flow

    that's the curse of xep60

  82. flow

    everytime you read it, something new appears

  83. jonas’

    we should read it more often

  84. jonas’

    maybe we’ll get the perfect eierlegendewollmilchsau spec then

  85. jonas’

    because it evolves on its own

  86. flow

    wouldn't that only make that monstrosity bigger?

  87. Zash

    what if it grows by a rate determined by its size?

  88. Zash

    and most other XEPs are too small to grow on their own

  89. jonas’

    a panxepic?

  90. lovetox

    flow, it really unfortunate how you push such a change to the XEP, without any implementor requesting something like that

  91. jonas’

    lovetox, Experimental.

  92. lovetox

    the pro and cons where never discussed

  93. lovetox

    you just heard of that fancy 0060 feature and decided, hey i will use that

  94. flow

    lovetox, I did not publish any substantial changes, plus it is experimental, plus I don't see the problem

  95. lovetox

    i tell you now it sucks

  96. flow

    lovetox, I did not publish any substantial changes, plus it is experimental, plus I don't see the problem witht he current version

  97. flow

    care to elaborate? I am happy to discuss it

  98. lovetox

    i just told you

  99. flow

    that you have to remember the last item id of the metadata node per contact?

  100. flow

    what is the alternative?

  101. Zash

    The über-basic PEP implementation in Prosody that I don't think anyone uses defaults the item id to "1" :)

  102. Neustradamus

    It is good to talk about old problems :)

  103. lovetox

    are you saying your XEP was not working before this change?

  104. lovetox

    because that is the alternativ

  105. lovetox

    im not sure why you changed that at all, many xeps use metadata nodes, and you made it a metadata node, that sends notification without payload, so meta meta

  106. flow

    well before you had to remember the set of openpgp key fingerprints, now it's only a single item id

  107. lovetox

    and now we have to store more data

  108. Zash

    Newer one seems to use UUIDv4

  109. lovetox

    are you saying your change makes it so that i am now able to not store any public keys?

  110. flow

    lovetox, I am sorry, I do not understand that question, could you rephrase it please?

  111. lovetox

    > well before you had to remember the set of openpgp key fingerprints,

  112. lovetox

    this sentence implies i dont have to store public keys anymore

  113. jonas’

    so as I see it, lovetox’ problem is that before the change, a client would get pushed the full key fingerprints. no persistence of that required and you can use the local gpg keyring for persistence of the keys. after the change, you now need to remember the item ID per contact and you need an extra roundtrip to obtain the fingerprints, and then another roundtrip to download the keys.

  114. jonas’

    this however buys a saving of bandwidth.

  115. lovetox

    yes thanks for the summary

  116. flow

    jonas’, I think you could still simply not store the fingerprints, and instead pull them

  117. flow

    before the change, one could argue that you got the fingerprints pushed

  118. flow

    but if you really do not want to remember the last item id, nothing prevents you from pulling them

  119. jonas’

    except that pulling is more expensive

  120. lovetox

    ok im out

  121. jonas’

    but it’s opt-in

  122. jonas’

    so it’s a trade-off

  123. flow

    that design, and especially the tradeoff inovled, appeared sensible to me. but if there is some follow up discussion required, then please start one on standards@ and if there is consensus that this not the "right" way then we can change it (again, it is an experimental XEP)

  124. jonas’

    (and by opt-in I mean you can easily do it selectively for the most recent/important contacts, while you cannot +notify for only a few contacts)

  125. jonas’

    (though you could explicitly subscribe, hm)

  126. flow

    that design, and especially the tradeoff involved, appeared sensible to me. but if there is some follow up discussion required, then please start one on standards@ and if there is consensus that this not the "right" way then we can change it (again, it is an experimental XEP)

  127. jonas’

    flow, I do see some merit in discussing changes in Experimental XEPs with deployments with the community though

  128. jonas’

    even though you’re the author

  129. jonas’

    MattJ gave us a very good example of that with the recent MAM changes

  130. flow

    sure, when the xep was initially developed we held monthly meetings

  131. flow

    but to be frank, I did not the changes to be that significant. I can see now that others may feel different

  132. flow

    but to be frank, I did not consider the changes to be that significant. I can see now that others may feel different

  133. jonas’

    it is significant, because a client running the old code will be confused about the empty notifications *and* its pep implementation may choose item IDs (e.g. 'current') which break things

  134. flow

    it was underspecified if the notification is with or without payload, so any implementation assumption about it could be argued to be wrong

  135. pep.

    So this is a "clarification" :p

  136. flow

    furthermore, I don't see a discussion about 'current' in xep163, did I miss it?

  137. jonas’

    "clarification" should be a taboo-word

  138. pep.

    Indeed

  139. flow

    and even if there was one, it was also not specified if singleton nodes are used or not, so the same applies here

  140. jonas’

    flow, it’s in '60 even

  141. jonas’

    https://xmpp.org/extensions/xep-0060.html#impl-singleton

  142. jonas’

    I thought this was just PEP

  143. flow

    jonas’, I was searching for a place which told me that pep nodes are considered to be singletons

  144. flow

    I am aware of the singleton specification in xep60

  145. jonas’

    oh, that they most certainly are not

  146. pep.

    Not all PEP nodes are singletons are they

  147. jonas’

    as I said

  148. pep.

    But lots are

  149. jonas’

    true

  150. Neustradamus

    https://github.com/xsf/xeps/issues/966 already closed, strange about publication date problem!

  151. pep.

    Neustradamus, yes I closed it. Who cares

  152. pep.

    jonas’ explained it to you already

  153. Neustradamus

    It is not in the ticket

  154. pep.

    I summarized it in there

  155. Neustradamus

    But the problem is always here

  156. pep.

    The problem is in your head

  157. Neustradamus

    No

  158. Neustradamus

    The change has been few days ago, not in 2018.

  159. Neustradamus

    A best example of chronology problem

  160. flow

    I guess due git, some (most?) developers are aware that "events" sometimes do not happen in a chronological order

  161. flow

    sure, the a xep revision history is not the log of a vcs, but still

  162. flow

    sure, a xep revision history is not the log of a vcs, but still

  163. jonas’

    I explained in more detail what happened in the ticket just now, Neustradamus

  164. jonas’

    Neustradamus, I know that we have a language barrier, and thinking further, in this case you are right about pointing it out.

  165. jonas’

    We cannot fix it anymore though, "the ship has sailed".

  166. jonas’

    (if someone who shares a native language with Neustradamus would translate the thing I just commented on the issue, I’d be grateful: https://github.com/xsf/xeps/issues/966#issuecomment-648374775 )

  167. Zash

    At least nobody yells at me when I rebase things from 3 years ago and publish them without touching the date.

  168. jonas’

    in this case, it can actually cause problems with editor tooling which goes by the date of the most recent revision

  169. jonas’

    if that’s not monotonic, incorrect deferrals will happen

  170. jonas’

    not a problem in this specific case, since both changes are merely editorial

  171. flow

    jonas’, btw your summary above was not entirely correct. even before the change, you could not rely on the persistence of the OpenPGP implementation, as, and yes that not frequently done but nevertheless happens, a master key could, for example, get new subkeys

  172. jonas’

    uh, that’s a no fun edge case

  173. flow

    and I think that with the current state, you don't have to remember the the item id, but it makes things easier and more reliable

  174. flow

    not sure if I would describe it as edge case, openpgp impls are able to deal with it today too

  175. jonas’

    but you need to poll keyservers to make it work ;)

  176. pep.

    yeah and you might not want to link OX with keyservers

  177. flow

    pep., don't want to and don't need to

  178. flow

    the link with the keyservers is established by the key's fingerprint

  179. Zash

    Aren't keyservers dead now?

  180. jonas’

    in this case, the PEP node is the keyserver

  181. flow

    otoh since the openpgp keyserver network is somewhat partioned…

  182. flow

    Zash, down to one operator

  183. flow

    not completely dead

  184. flow

    and there is always the keyserver from openpgp.org

  185. Zash

    Dead and replaced by web. Yay!

  186. jonas’

    much less useful though since you can’t publish signatures anymore

  187. jonas’

    (or if you can, it’s dead ;))

  188. flow

    jonas’, depends on your point of view. I do think that the web of trust was a good nor workable idea, and I also do not like to publish my signatures for everyone to see

  189. flow

    for one, it makes it easier to trace the contacts I had, and on the other hand I am not sure what anyone would want to do with that information (which bridges back to the "WOT was a terrible idea" thought)

  190. pep.

    Yeah, publishing my whole contact network is not one of my favorite hobbies either

  191. flow

    but I'll admit that I'd liked the idea of the WoT when I created my first OpenPGP key 20 years ago ;)

  192. jonas’

    signatures are useful even without considering WoT when you migrate keys

  193. jonas’

    and by migrate, I mean roll over

  194. flow

    ok, that's one example where publishing a signature is sensible

  195. jonas’

    or when you have separate keys for organizations you’re affiliated with, which you sign with your personal master key

  196. flow

    not sure if there are other examples, maybe

  197. pep.

    jonas’, I made the "mistake" to use a single key for all, now it seems I'm "stuck" with all these identities (keyservers won't remove them)

  198. flow

    hmm cross siging is double edged sword, I am not sure about it

  199. flow

    pep., keyservers can't remove them (I think)

  200. jonas’

    pep., yeah, I was luckily smart enough about that

  201. jonas’

    or the company was

  202. pep.

    yeah which is terrible. But then thinking that you don't have to authenticate to push a key anyway..

  203. pep.

    (I think?)

  204. jonas’

    they want a revocation certificate from each employees (work) gpg keys :)

  205. flow

    pep., keys.gnupg.net has mail based authentication

  206. flow

    err no

  207. flow

    I mean keys.openpgp.org of course

  208. pep.

    My previous company didn't care about GPG at all, it was just me using it because I wanted

  209. jonas’

    (of course, anyone looking at my gpg key sees immediately that I wasn’t that smart enough at all times)

  210. jonas’

    pep., you can do a key rollover though, like I did some time back from RSA 2048 to RSA 4096. since you’ll be re-creating everything anyways, you can split your identities there, to

  211. jonas’

    pep., you can do a key rollover though, like I did some time back from RSA 2048 to RSA 4096. since you’ll be re-creating everything anyways, you can split your identities there, too

  212. flow

    well you shouldn't need to be smart to use crypto

  213. jonas’

    flow, yeah, user agents can do a lot here

  214. jonas’

    but you need a bit of smartness to not use your personal email for work stuff, too ;)

  215. jonas’

    same thing, really

  216. pep.

    it's a bit more complex when your work involves free software stuff to which you also contribute in your free time :x

  217. pep.

    And if you switch jobs you'll continue working on it in your new job anyway :p

  218. pep.

    Might as well keep the same identity within the project

  219. jonas’

    oh, I like to keep that strictly separated actually

  220. jonas’

    reminds me that I still have that PR open which I can’t work on at $workplace anymore…

  221. pep.

    I managed to do it for like a week, have separate profiles and all on my laptop, and then I gave up..

  222. jonas’

    I have a different laptop. helps :)

  223. DebXWoody

    It's possible to export your key like this: gpg --export --export-options export-minimal --export-filter 'keep-uid=uid =~ xmpp:local@domain.tld' MY_FINGERPRINT > /tmp/test.gpg There are no signatures in the export and there is just the xmpp-URI as UID.

  224. DebXWoody

    If you do not prefer to use WoT you can use trust-model TOFO. This can be used for "non-technical" users. But the WoT doesn't mean you must publish the key via keyserver or to publish the "full" key to the keyserver. It's also possible to share the public key with signatures afterwards. I prefer to use a dedicated key just for signing.

  225. flow

    DebXWoody, I refer to the idea that the information that I signed another person's key is of any use to you as the wot. And I think the idea is simply flawed

  226. Neustradamus

    https://github.com/xsf/xeps/issues/966#issuecomment-648399750

  227. jonas’

    We do not have an official publication date.

  228. jonas’

    Show me where some document states that the date in the revision history is the publication date.

  229. pep.

    The one thing I'd like in relation to this is that actually have the latest date at the top of the document (In addition to "Version", iff different maybe)

  230. pep.

    I mean last modified

  231. pep.

    But that's different to things being chronological

  232. pep.

    (It might help also to have things chronological but it's not a necessary condition, is what I mean)

  233. jonas’

    pep., note that by policy, there are no chagnes to the text which do not also create a revision block

  234. Neustradamus

    Example: Only one, XEP-0292 (with a random choice): - https://xmpp.org/extensions/xep-0292.html Version 0.1 (2011-03-02) - https://mail.jabber.org/pipermail/standards/2011-March/024199.html Of course, there is the time zone.

  235. pep.

    Yeah, it's a small corner case (in XEPs, otherwise it's fairly common) but it happens to have a non-chronological revision history.

  236. pep.

    Neustradamus, can you explain what I should be looking at?

  237. Neustradamus

    Thousands of examples exist ;)

  238. pep.

    Examples of what

  239. pep.

    Nothing states in 0292 that revision history has to be chronological

  240. jonas’

    are you complaining about 2011-03-03 vs. 2011-03-02?

  241. Neustradamus

    It is the date!

  242. pep.

    ah

  243. jonas’

    Neustradamus, okay, at this point, I have to ask you to shut up about this. This is costing time and energy of the editor team for zero (in numbers: 0) gain.

  244. pep.

    Neustradamus, I guess you already have a script or something to find out all the relevant files to update and you can submit a PR?

  245. jonas’

    I would *not* accept that PR

  246. pep.

    Adding of course a revision block in each of the edited XEP

  247. jonas’

    we will not rewrite existing revision blocks, unless there is an order from council or board to do so.

  248. jonas’

    they are in a strange meta-space between the text and revisions itself, and they are kind of unversioned and messing with them makes my head hurt

  249. pep.

    Well that would be a starting point if he wanted such a change to be made I guess

  250. jonas’

    I want to nip this in the bud.

  251. jonas’

    this is a waste of time and energy

  252. Neustradamus

    A commit with the date of publication/announcement/release is needed, it is easy

  253. Neustradamus

    You can see the problem with XEP-0390

  254. pep.

    jonas’, I agree

  255. jonas’

    Neustradamus, it is *not* easy

  256. jonas’

    in contrast to you, I tried to do that

  257. jonas’

    and it is *not* easy

  258. jonas’

    if you can do it, be my guest, i’d like to have a tool which maps a commit ID to a revision

  259. jonas’

    but it is surprisingly tricky with merges and stuff

  260. Neustradamus

    The editor do a little commit, easy.

  261. jonas’

    no it’s not

  262. jonas’

    if it’s easy, show me how easy it is

  263. Neustradamus

    The editor does a little commit, easy.

  264. jonas’

    you can do everything I can do in xeps, except hitting the green button which makes it go live

  265. jonas’

    show me how easy it is, make a pull request

  266. Neustradamus

    How it was done before? There was not a date problem ;)

  267. jonas’

    Neustradamus, mistakes happen.

  268. jonas’

    I have no idea how everyone has been perfect in the past, I guess I should resign.