XSF Discussion - 2020-06-23

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

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

How's this of relevance to XMPP?

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

> 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!

yeah that's awful

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.

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

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

pep.: yeah, the irony is overwhelming

Ge0rG What does "match-making" mean?

Finding other people to play with?

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!

do we have diff service between 2 xep versions?

or how are you guys doing that

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

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

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

thanks Neustradamus

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

why is the metadata node now payload less

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

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

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

tell me if i should bribe someone

note the "may" in the sentence ;)

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

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

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

* 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 *

*twitch*

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

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

:-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

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

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

DebXWoody, with a version appended?

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

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

ah

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

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

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

*older revisions

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

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

flow what ID?

err item id

lovetox, pubsub item id

you dont mandate anything about the ID

"current" \o/

the id could be "current" for all notifications

IIRC xep60 does

no it doesnt

I think it does

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

That?

no xep60

Zash thats not the node we are talking about

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

flow why do you think there is no item id set

Where?

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

no?

so then this whole approach just does not work

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

since that has numerous advantages

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

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

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

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

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

just to know if something changed

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

Huh but it varies

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

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

that's the curse of xep60

everytime you read it, something new appears

we should read it more often

maybe we’ll get the perfect eierlegendewollmilchsau spec then

because it evolves on its own

wouldn't that only make that monstrosity bigger?

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

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

a panxepic?

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

lovetox, Experimental.

the pro and cons where never discussed

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

i tell you now it sucks

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

care to elaborate? I am happy to discuss it

i just told you

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

what is the alternative?

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

It is good to talk about old problems :)

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

because that is the alternativ

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

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

and now we have to store more data

Newer one seems to use UUIDv4

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

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

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

this sentence implies i dont have to store public keys anymore

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.

this however buys a saving of bandwidth.

yes thanks for the summary

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

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

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

except that pulling is more expensive

ok im out

but it’s opt-in

so it’s a trade-off

(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)

(though you could explicitly subscribe, hm)

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) ✏

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

even though you’re the author

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

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

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

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

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

So this is a "clarification" :p

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

"clarification" should be a taboo-word

Indeed

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

flow, it’s in '60 even

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

I thought this was just PEP

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

I am aware of the singleton specification in xep60

oh, that they most certainly are not

Not all PEP nodes are singletons are they

as I said

But lots are

true

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

Neustradamus, yes I closed it. Who cares

jonas’ explained it to you already

It is not in the ticket

I summarized it in there

But the problem is always here

The problem is in your head

No

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

A best example of chronology problem

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

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

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

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

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

(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 )

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

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

if that’s not monotonic, incorrect deferrals will happen

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

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

uh, that’s a no fun edge case

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

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

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

yeah and you might not want to link OX with keyservers

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

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

Aren't keyservers dead now?

in this case, the PEP node is the keyserver

otoh since the openpgp keyserver network is somewhat partioned…

Zash, down to one operator

not completely dead

and there is always the keyserver from openpgp.org

Dead and replaced by web. Yay!

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

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

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

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)

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

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

signatures are useful even without considering WoT when you migrate keys

and by migrate, I mean roll over

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

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

not sure if there are other examples, maybe

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)

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

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

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

or the company was

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

(I think?)

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

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

err no

I mean keys.openpgp.org of course

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

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

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 ✏

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

flow, yeah, user agents can do a lot here

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

same thing, really

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

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

Might as well keep the same identity within the project

oh, I like to keep that strictly separated actually

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

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

I have a different laptop. helps :)

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.

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.

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

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

We do not have an official publication date.

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

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)

I mean last modified

But that's different to things being chronological

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

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

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.

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

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

Thousands of examples exist ;)

Examples of what

Nothing states in 0292 that revision history has to be chronological

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

It is the date!

ah

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.

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?

I would *not* accept that PR

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

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

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

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

I want to nip this in the bud.

this is a waste of time and energy

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

You can see the problem with XEP-0390

jonas’, I agree

Neustradamus, it is *not* easy

in contrast to you, I tried to do that

and it is *not* easy

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

but it is surprisingly tricky with merges and stuff

no it’s not

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

The editor does a little commit, easy. ✏

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

show me how easy it is, make a pull request

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

Neustradamus, mistakes happen.

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