MattJThe most interesting part of that is that they are merging the brand of Riot (open-source client) with the brand of their commercial stuff
ZashHow's this of relevance to XMPP?
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".
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!
pep.yeah that's awful
Ge0rGfunny 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.
Neustradamuslovetox: You can comment on it, add an emoji...
NeustradamusBut 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
lovetoxflow, care to elaborate on your change in 0373 regarding notification-only nodes
lovetoxwhy is the metadata node now payload less
lovetoxas i see it this would prevent me from knowing if keys have changed
jonas’lovetox, XEP diffs may be viable with gitlab-based infrastructure (or when someone smarter than me figures out all the equivalents in github)
lovetoxok jonas’ nice, you have all my support on your gitlab endeavor !
lovetoxtell me if i should bribe someone
jonas’note the "may" in the sentence ;)
ZashI've got stuff based on conversion to markdown before diffing, but that's of course unusable to anyone else.
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
jonas’lovetox, that would "just" need someone who puts such a service in a docker container d)
jonas’lovetox, that would "just" need someone who puts such a service in a docker container :)
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 *
jonas’moparisthebest, it’s your fault if everything stalls now while I create a similar insanity in sed
moparisthebestrubs hands evilly
jonas’though for this complexity, I’d probably first have to complete my assembly-to-sed compiler
DebXWoodyIt would be nice to have the current version in the same style like the attic files.
jonas’DebXWoody, I don’t follow, what do you mean regarding the style?
pep.DebXWoody, with a version appended?
pep.That would require proposed changed to be in the attic though, to answer lovetox's comment
DebXWoodyjonas’, 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
ZashThis be why you'd wanna compare the source XML, not the output HTML
flowlovetox, the node id will tell you if you have the latest item of that node
jonas’DebXWoody, ah, that’s true, but only for older XEPs
jonas’unfortunately, we have no technically feasible way to re-render the old versions
jonas’(in some cases, I don’t think we even have the XML of the old versions anymore, since that might be pre-git)
lovetoxflow what ID?
flowerr item id
jonas’lovetox, pubsub item id
lovetoxyou dont mandate anything about the ID
lovetoxthe id could be "current" for all notifications
flowIIRC xep60 does
lovetoxno it doesnt
flowI think it does
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.
lovetoxZash thats not the node we are talking about
flowsomething along the lines that if no item id is set, then the service should create a unique one
lovetoxflow why do you think there is no item id set
lovetoxdoes your XEP mandate that it is imperativ that NO item id is iset
lovetoxso then this whole approach just does not work
jonas’flow, what lovetox says is relevant, since PEP stuff typically will use id='current'
jonas’since that has numerous advantages
flowhappy to clarify that current shouldn't be use for the metadata node
flowhappy to clarify that current shouldn't be used for the metadata node
flowbut I wasn't aware that PEP mandates the use of 'current' as item id in the spec
lovetoxhm would not really make me happy, did you think about what that means for clients now?
lovetoxthis means i have to have a database of all contacts and the last item id i saw from them
> if [the] publish request did not include [an] item ID, pubsub service MUST generate item ID
lovetoxjust to know if something changed
flowlovetox, you don't have to, you can also fetch the keys from all contacts everytime you connect
jonas’I swear this table wasn’t there the last time I read xep60
flowthat's the curse of xep60
floweverytime you read it, something new appears
jonas’we should read it more often
jonas’maybe we’ll get the perfect eierlegendewollmilchsau spec then
jonas’because it evolves on its own
flowwouldn't that only make that monstrosity bigger?
Zashwhat if it grows by a rate determined by its size?
Zashand most other XEPs are too small to grow on their own
lovetoxflow, it really unfortunate how you push such a change to the XEP, without any implementor requesting something like that
lovetoxthe pro and cons where never discussed
lovetoxyou just heard of that fancy 0060 feature and decided, hey i will use that
flowlovetox, I did not publish any substantial changes, plus it is experimental, plus I don't see the problem
lovetoxi tell you now it sucks
flowlovetox, I did not publish any substantial changes, plus it is experimental, plus I don't see the problem witht he current version
flowcare to elaborate? I am happy to discuss it
lovetoxi just told you
flowthat you have to remember the last item id of the metadata node per contact?
flowwhat is the alternative?
ZashThe über-basic PEP implementation in Prosody that I don't think anyone uses defaults the item id to "1" :)
NeustradamusIt is good to talk about old problems :)
lovetoxare you saying your XEP was not working before this change?
lovetoxbecause that is the alternativ
lovetoxim 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
flowwell before you had to remember the set of openpgp key fingerprints, now it's only a single item id
lovetoxand now we have to store more data
ZashNewer one seems to use UUIDv4
lovetoxare you saying your change makes it so that i am now able to not store any public keys?
flowlovetox, I am sorry, I do not understand that question, could you rephrase it please?
lovetox> well before you had to remember the set of openpgp key fingerprints,
lovetoxthis sentence implies i dont have to store public keys anymore
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.
jonas’this however buys a saving of bandwidth.
lovetoxyes thanks for the summary
flowjonas’, I think you could still simply not store the fingerprints, and instead pull them
flowbefore the change, one could argue that you got the fingerprints pushed
flowbut if you really do not want to remember the last item id, nothing prevents you from pulling them
jonas’except that pulling is more expensive
lovetoxok im out
jonas’but it’s opt-in
jonas’so it’s a trade-off
flowthat 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)
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)
jonas’(though you could explicitly subscribe, hm)
flowthat 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)
jonas’flow, I do see some merit in discussing changes in Experimental XEPs with deployments with the community though
jonas’even though you’re the author
jonas’MattJ gave us a very good example of that with the recent MAM changes
flowsure, when the xep was initially developed we held monthly meetings
flowbut to be frank, I did not the changes to be that significant. I can see now that others may feel different
flowbut to be frank, I did not consider the changes to be that significant. I can see now that others may feel different
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
flowit was underspecified if the notification is with or without payload, so any implementation assumption about it could be argued to be wrong
pep.So this is a "clarification" :p
flowfurthermore, I don't see a discussion about 'current' in xep163, did I miss it?
jonas’"clarification" should be a taboo-word
flowand even if there was one, it was also not specified if singleton nodes are used or not, so the same applies here
flowjonas’, I was searching for a place which told me that pep nodes are considered to be singletons
flowI am aware of the singleton specification in xep60
jonas’oh, that they most certainly are not
pep.Not all PEP nodes are singletons are they
jonas’as I said
pep.But lots are
Neustradamushttps://github.com/xsf/xeps/issues/966 already closed, strange about publication date problem!
pep.Neustradamus, yes I closed it. Who cares
pep.jonas’ explained it to you already
NeustradamusIt is not in the ticket
pep.I summarized it in there
NeustradamusBut the problem is always here
pep.The problem is in your head
NeustradamusThe change has been few days ago, not in 2018.
NeustradamusA best example of chronology problem
flowI guess due git, some (most?) developers are aware that "events" sometimes do not happen in a chronological order
flowsure, the a xep revision history is not the log of a vcs, but still
flowsure, a xep revision history is not the log of a vcs, but still
jonas’I explained in more detail what happened in the ticket just now, Neustradamus
jonas’Neustradamus, I know that we have a language barrier, and thinking further, in this case you are right about pointing it out.
jonas’We cannot fix it anymore though, "the ship has sailed".
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 )
ZashAt least nobody yells at me when I rebase things from 3 years ago and publish them without touching the date.
jonas’in this case, it can actually cause problems with editor tooling which goes by the date of the most recent revision
jonas’if that’s not monotonic, incorrect deferrals will happen
jonas’not a problem in this specific case, since both changes are merely editorial
flowjonas’, 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
jonas’uh, that’s a no fun edge case
flowand 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
flownot sure if I would describe it as edge case, openpgp impls are able to deal with it today too
jonas’but you need to poll keyservers to make it work ;)
pep.yeah and you might not want to link OX with keyservers
flowpep., don't want to and don't need to
flowthe link with the keyservers is established by the key's fingerprint
ZashAren't keyservers dead now?
jonas’in this case, the PEP node is the keyserver
flowotoh since the openpgp keyserver network is somewhat partioned…
flowZash, down to one operator
flownot completely dead
flowand there is always the keyserver from openpgp.org
ZashDead and replaced by web. Yay!
jonas’much less useful though since you can’t publish signatures anymore
jonas’(or if you can, it’s dead ;))
flowjonas’, 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
flowfor 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)
pep.Yeah, publishing my whole contact network is not one of my favorite hobbies either
flowbut I'll admit that I'd liked the idea of the WoT when I created my first OpenPGP key 20 years ago ;)
jonas’signatures are useful even without considering WoT when you migrate keys
jonas’and by migrate, I mean roll over
flowok, that's one example where publishing a signature is sensible
jonas’or when you have separate keys for organizations you’re affiliated with, which you sign with your personal master key
flownot sure if there are other examples, maybe
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)
flowhmm cross siging is double edged sword, I am not sure about it
flowpep., keyservers can't remove them (I think)
jonas’pep., yeah, I was luckily smart enough about that
jonas’or the company was
pep.yeah which is terrible. But then thinking that you don't have to authenticate to push a key anyway..
jonas’they want a revocation certificate from each employees (work) gpg keys :)
flowpep., keys.gnupg.net has mail based authentication
flowI mean keys.openpgp.org of course
pep.My previous company didn't care about GPG at all, it was just me using it because I wanted
jonas’(of course, anyone looking at my gpg key sees immediately that I wasn’t that smart enough at all times)
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
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
flowwell you shouldn't need to be smart to use crypto
jonas’flow, yeah, user agents can do a lot here
jonas’but you need a bit of smartness to not use your personal email for work stuff, too ;)
jonas’same thing, really
pep.it's a bit more complex when your work involves free software stuff to which you also contribute in your free time :x
pep.And if you switch jobs you'll continue working on it in your new job anyway :p
pep.Might as well keep the same identity within the project
jonas’oh, I like to keep that strictly separated actually
jonas’reminds me that I still have that PR open which I can’t work on at $workplace anymore…
pep.I managed to do it for like a week, have separate profiles and all on my laptop, and then I gave up..
jonas’I have a different laptop. helps :)
DebXWoodyIt's possible to export your key like this:
gpg --export --export-options export-minimal --export-filter 'keep-uid=uid =~ xmpp:firstname.lastname@example.org' MY_FINGERPRINT > /tmp/test.gpg
There are no signatures in the export and there is just the xmpp-URI as UID.
DebXWoodyIf 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.
flowDebXWoody, 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
jonas’We do not have an official publication date.
jonas’Show me where some document states that the date in the revision history is the publication date.
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)
pep.I mean last modified
pep.But that's different to things being chronological
pep.(It might help also to have things chronological but it's not a necessary condition, is what I mean)
jonas’pep., note that by policy, there are no chagnes to the text which do not also create a revision block
NeustradamusExample: Only one, XEP-0292 (with a random choice):
Version 0.1 (2011-03-02)
Of course, there is the time zone.
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.
pep.Neustradamus, can you explain what I should be looking at?
NeustradamusThousands of examples exist ;)
pep.Examples of what
pep.Nothing states in 0292 that revision history has to be chronological
jonas’are you complaining about 2011-03-03 vs. 2011-03-02?
NeustradamusIt is the date!
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.
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?
jonas’I would *not* accept that PR
pep.Adding of course a revision block in each of the edited XEP
jonas’we will not rewrite existing revision blocks, unless there is an order from council or board to do so.
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
pep.Well that would be a starting point if he wanted such a change to be made I guess
jonas’I want to nip this in the bud.
jonas’this is a waste of time and energy
NeustradamusA commit with the date of publication/announcement/release is needed, it is easy
NeustradamusYou can see the problem with XEP-0390
pep.jonas’, I agree
jonas’Neustradamus, it is *not* easy
jonas’in contrast to you, I tried to do that
jonas’and it is *not* easy
jonas’if you can do it, be my guest, i’d like to have a tool which maps a commit ID to a revision
jonas’but it is surprisingly tricky with merges and stuff
NeustradamusThe editor do a little commit, easy.
jonas’no it’s not
jonas’if it’s easy, show me how easy it is
NeustradamusThe editor does a little commit, easy.
jonas’you can do everything I can do in xeps, except hitting the green button which makes it go live
jonas’show me how easy it is, make a pull request
NeustradamusHow it was done before?
There was not a date problem ;)
jonas’Neustradamus, mistakes happen.
jonas’I have no idea how everyone has been perfect in the past, I guess I should resign.