XSF Discussion - 2018-08-01

hi everyone

Greetings!

I was wondering it there is a way to quote/reference a pubsub item in a chat message ?

there's muc#roominfo_pubsub that allows to link Pubsub nodes to a MUC, and I'm planning to display the related pubsub node items in the MUC UI, then you can comment/reference it

edhelas, the References XEP has a syntax for that I think

\o/

... a syntax which I don’t like, and I haven’t heard back from the authors yet on whether they’re willing to change it

jdev@conference.jabber.org will respond to pings to a non-existent nickname with not-allowed. Yay.

this muc is fubar anyways

It will also respond not-allowed if I'm not joined.

purrfect

> this muc is fubar anyways Which is why I'm testing it.

jonasw: https://github.com/xsf/xeps/pull/688

I need an "Out of Order -- Overheated" sign

Ge0rG, no revision block documenting the rename etc.?

Wasn't there a 'hot' in {xep user mood}?

Zash: User Mood (Standards Track, Draft, 2018-03-13) See: https://xmpp.org/extensions/xep-0107.html

Ge0rG, another suggestion: I think a safe way to handle nickname-change-vs-ping-races is the following: when receiving a nickname change notification *and* a ping is in-flight, that ping is allowed to fail. issue a new ping.

due to the stream ordering guarantees, you have to see the nick change notification *before* the error reply

s/issue a new ping/issue a new ping and ignore the result of the other ping/

jonasw: or do what I did in the PR ;)

consider item-not-found as a valid response

Ge0rG, but what if you never get a response because just in that moment your s2s interrupts?

(talking about line 172+)

my suggestion resolves MSN and own nick changes and it’ll work even with jdev@

jonasw: your suggestion requires more logic.

Ge0rG, it’s also fail-safer

jonasw: I can live with yet another rejoin ;)

maybe put it in as suggestion for clients which want that amount of logic

jonasw: PRs welcome

on a ProtoXEP?

jonasw: it will stay a ProtoXEP until daniel approves or rejects.

still, you wanna add your revision block there?

jonasw: do I need to? I only asked for the revision block for the case that the funny name has to leave the title.

for the sake of record-keeping and e.g. daniel who has to review it later, it makes sense to record it

jonasw: as the Council didn't provide much feedback on the technical details, I'm not sure it will matter to daniel

put it another way: if you don’t do it, I’ll do it

but if you do it now, I can merge that now

if you don’t do it now, I’ll drag it out because it’s too hot for me to think about stuff

Or until Daniel doesn't vote. There's a two week expiry period on voting.

Kev: that's an option as well. But I don't want to delay changes based on the Council feedback by two weeks because of that.

If I'm reading XEP-0060 right, you can't support max_items and simultaneously support unlimited items

Hmm, more simply - there is just no way to have an unlimited-item node

Set max_items > 9000

Seems like quite a limitation for e.g. microblogging

640K Ought to be Enough for Anyone <https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=2&amp;ved=2ahUKEwjDrZWPuczcAhUBvVkKHXecAi0QFjABegQIAhAB&amp;url=https%3A%2F%2Fquoteinvestigator.com%2F2011%2F09%2F08%2F640k-enough%2F&amp;usg=AOvVaw1pt8pBSu4B_G2oN6QxGUP0>

640K Ought to be Enough for Anyone <https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=2&amp;ved=2ahUKEwjDrZWPuczcAhUBvVkKHXecAi0QFjABegQIAhAB&amp;url=https%3A%2F%2Fquoteinvestigator.com%2F2011%2F09%2F08%2F640k-enough%2F&amp;usg=AOvVaw1pt8pBSu4B_G2oN6QxGUP0>

Set max_items to be, dynamically, 10k more than the current count.

But yeah, you're right. If an implementation supports multiple items, it has to expose max_items.

So people complained Prosody's PEP only supported a single item

so how many did they want it to support?

Let's say OMEMO used an item per device for keys, what would Conversations configure max_items as?

MattJ, Well, Prosody can support unlimited items, or at least, support any value for max_items.

MattJ, I don't know without looking if there's an upper limit on max_items because it's a xs:positiveInteger, mind, but I'd expect that to be 2**31 at worst case.

MattJ, That said, pre-keys are stored in PEP precisely to obviate the need for server code changes, and given that storing them in "the open" potentially leads to a kind of DoS(ish) attack which weakens the cryptographic properties, it's arguing to stick pre-keys in a specialized server-side service anyway.

MattJ, But bookmarks 2 uses multiple items, too, for better reasons.

Im not sure if im understanding you correctly, but omemo does not store multiple items

it needs exactly one item per node

It could tho

but it does not care if its more

Zash i dont see the value

But it doesn't because it wouldn't work since only one item was guaranteed

im not sure what you are suggesting, but i dont see any value in storing anything omemo related in a multiple items node

bookmarks is completely different use case

and it makes sense there

individual prekeys could be removed when they are used up for example

and devices could publish their own key without having to make sure to not remove other devices keys

tricky, a prekey in a node is not of any value if you dont have the same prekey in storage

its more foolproof if you just publish the new prekey list on each removal

I don't actually have any idea how OMEMO works, I'm just guessing

no you brought up a valid argument

one could do it that way, but then you would have to check from time to time, if your db stored prekeys are really the ones that are published

the second idea, to store device ids per item is more interesting

Altho, it uses ... different nodes now? Or something?

Which in itself is awkward

you mean the device id?

its serves a multi purpose, 1. it shows you the way to the public key node

Sorry, my question was quite unrelated to OMEMO, it was just an example (multiple items have been discussed in the past, and Prosody not supporting that was one of the reasons against it)

2. it shows other clients which devices are active devices

Bookmarks is just as valid

And probably a better example

Both specs bend backwards a bit to fit into "there can be only one item per node"

MattJ, why do you ask, because you think about a hard max limit for prosody?

i guess its only natural that a server has something like that

i think nobody expects a server to support truly unlimited items

Zash i thought about it some more, and how would you chose a prekey? because more then one client can try to use a prekey while you are offline, you are supposed to choose one per random to reduce the chances that 2 c lients pick the same

so you have to download all items of the node

this does need 100 times the roundtrips you would need with one node, and needs much more time

*one item

If someone would want to improve the prekey use case, a server module is the best way

https://drive.google.com/file/d/1dbf75m-3HG7tssvI0L__99yNCj9mtPt4/view?usp=sharing (In progress) https://drive.google.com/file/d/1K7Y-5N3E0-swSOqmLHdgr7fyNHa0wjhj/view?usp=sharing (And done)

lovetox, FWIW, I'd like to make prekeying a server module, but I'd just wwait until MLS is ready and use that.

yes this would take some impl complexity away from clients and additionally would make race conditions impossible

lovetox, Also means you can't "drain" prekeys, or look for especially weak ones to use, or ...

lovetox, It *also* means that a server can potentially inject other prekeys into a set, of course. That ought to be detectable, but it can allow for retention policies etc which are important in enterprise/government cases.

hm really? would not still the client have to create the keys and suppy it to the server?

lovetox, Yes, but the server can conceal how many are present and loop over the last N instead of discarding them.

lovetox, Anyone trying to constantly request prekeys to see if this is the case is pretty easy to spot, too.

hm no that is not allowed in the signal spec

prekey is to used once only

lovetox, I know. But the MLS spec isn't Signal, just similar. And prekeys can't be used more than once mostly to make the cryptographic proofs simpler.

lovetox, The alternative is that if prekeys are exhausted, then you can't exchange messages (encrypted) anymore.

lovetox, So either that's a DoS waiting to happen, or else unencrypted comms.

lovetox [19:47]: > MattJ, why do you ask, because you think about a hard max limit for prosody? Yes, we need a limit