XSF Discussion - 2019-03-23

pep.: most have set their channels to allow registered users only, making them effectively useless for end user support

Why?

Registering your nick is very common for that platform?

For irc? It's a measure to combat spam. Last time freenode was attacked they required registered accounts, some channels still do.

ralphm: most OSS projects offer a web chat for support.

If you have some specific problem with a tool, you probably will rather give up in frustration than attempt to register an identity with an obscure 1990s underground network, especially through a web browser that doesn't even properly support identity management for that network

Hope you realize we are also working on a 1990s technology.

ietf site is down

did anyone remember all the standards

Oh noes

Hopefully they can fix the site now with https://ietf.org/blog/nokia-globalhost/ :D

In XEP-0313 MAM, section 3.5 specifies: "Servers MUST NOT include the <stanza-id/> element in messages addressed to JIDs that do not have permissions to access the archive, such as a users’s outgoing messages to their contacts."

Why is that a MUST NOT?

(XEP-0359 on the ID value of stanza-id: "The value of the 'id' attribute should not provide any further information besides the opaque ID itself. Entities observing the value MUST NOT be able to infer any information from it, e.g. the size of the message archive. The value of 'id' MUST be considered a non-secret value.")

If you can't query it, what purpose does it serve?

it does serve as a unique identifier. I'm not saying it makes much sense, but the 'MUST NOT' suggests that something horrible will happen if it does go out.

Guus, it's a combination of two things: 1) it used to be an <archived id='...' by='...' /> 2) sharing info on a need-to-know basis is a sensible default

Now it's morphed into a generic "stanza-id" element, which just happens to share ids with the MAM archive, I think it does make less sense

Sometimes I regret the <archived> -> <stanza-id> switch, sometimes I don't

heh

so, why would it be bad for an 'archived by' id?

I agree with it being a sensible default

but still, MUST NOT is quite strict

Because it can be used to the client as indication that the archive may be queried?

Why would you have an archive that someone doesn't have permission to access, and then share some of that data with them?

well, you SHOULD NOT. 🙂

But if you do, the client may assume it has permission, and will try to send you queries

which will result in errors.

meh

So why is this a problem to you?

it's not. I was just wondering.

I thought I was missing an important security aspect, or somesuch

On the one hand you have this argument. On the other hand you have people complaining about all the wiggle room in XEPs that use "SHOULD (NOT)" for no gain

I understand

So there's no concrete reason I can think of right now, but that happens to be what I thought best to write at the time

that's fair.

If we'd been using stanza-id from the start, I doubt I would have written it that way

I've got this annoying bit where carbons are sent off before the archiving takes place 😕

Guus: Sounds like our MUC pre-0.11, where messages are broadcasted before passing through the part where the MAM bits were attached

We need more message ids!

You can never have enough message ids

Zash, that sounds very much like what we have for Openfire now.

it's not very appealing to rewire all that, as it's making use of generic interceptors.

In case of a one-on-one chat between two local users, openfire is storing a message just once (as it stores 'conversations', not per user archives). That means that both virtual 'archives' would contain the exact same identifier.

XEP-313 says: " Thus the IDs defined in this extension MUST be unique and stable within the scope of the generating XMPP entity." which seems to allow it.

sorry, that's XEP-359

ah, 5.2 for XEP-313 also allows it

nevermind

... I now wonder if Openfire is, in effect, maintaining a message archive for non-local users.

It would be ... interesting ... if you could query your friends archives for messages to yourself

we don't keep "per user" archives.

we keep records of conversations

if a user queries for it's archive, that's retrieved from all conversations that the user was part of.

I mean from eg a remote server

That might be possible with Openfire...

I'm unsure what the retrieval query would look like, but I think we could answer the query, for all messages that you've sent on the local domain.

ah, we're explicitly not answering the query if sent by a non-local user.

Do we expect the archive ID to be added to <sent><forwarded> carbons, or only in <received><forwarded> ?

(the original sender doesn't get an echo of a server-generated stanza-id either, I think?)

No echo, but it must be added to <sent/> as well.

FWIW i aggree with Guus that the MUST NOT feels not well placed. I think we should simply remove the sentence if possible.

PRs welcome, I don't think it needs a namespace bump

I also don't think it needs one. And every little bit we can remove without "downgrading" the spec reduces the noise and makes it easier to understand and implement

I wasn't making much of a statement other than that I'm trying to determine if I understood the details right.

Ahh, Guus so you don't want to send a PR?

I'm not _against_ making one

but for now, my wife is giving me the stare 🙂

afk

I know that stare

And I always thought the stare was an uncommon phenomenom only happening to me

https://xmpp.org/extensions/xep-0277.html TIL this is not draft

!

Oh

That number is way too easy to confuse with https://xmpp.org/extensions/xep-0227.html

heh

Can we bring back bunneh to life?

Necromancy?

https://xmpp.org/extensions/xep-0277.html#receive can somebody explain what the Note means. I have a PR with a few typos in that XEP, I'd like to fix that as well. "Note: these alternate links were not posted by client because client can't compute them itself. These things SHOULD be inserted at server side though."

Ah I get it now

s/posted/generated/ or somesuch

I guess posted works as well

Odd wording IMO

"These alternate links were not posted by the original client because clients can't compute them themselves. [..]", at least

included, generated, computed

https://xmpp.org/extensions/xep-0277.html#metadata Do I understand correctly that this <item id='0'> MUST exist? :x

Or is it just if I want to provide metadata about my microblog

I think there should be a language review step before publishing :/

Huh

Yet another vcard?

Seems like it

Though, it is not impossible that people have access to your microblog but not your vcard right

(vcard4)

If you (the user) made one public but not the other then maybe you had a reason for that and it seems silly to bypass that and publish your personal info in more places

I'm not especially arguing for this metadata entry, but you might want to have a lesser version of your vcard to show for people looking at your (public) microblog, and a more complete version for your contacts

I mean I'm not arguing for implementing this in 277. That could be 292 with a different set of ACLs :-°

But anyway, we're going astray from my original question

... you want Bunneh secret sause?

I assume it's not a MUST then. it's an "if then MUST".

Is the goal to not require explicit server support?

hmm?

There is no "discovering support" section, I think those were mandatory?

Problematic to expect the server to maybe do stuff without any way to know that.

Personally I wish you could just post Atom to a node and be happy, but like every federated social feed protocol, the pain begins with replies and comments.