XSF Discussion - 2020-05-20

eevvoor, done

pep. :)

oh... here we go again :DD @eevvoor we are not specifically against (where did you get that from) but we simply won't drop just like that because there are other factors at play; *most likely* we will address it (0372?) but it will take some time. Besides, 0372 has it's own issue ("A begin attribute is used to mark the index in the body of the referring message of the first character (TODO: define character appropriately)", erm... :-) ) so it will take some time. and in case of other clients it boils down to having issue with detecting `@` + nick.

Wojtek, see https://xmpp.org/extensions/xep-0426.html

372 hasn't been updated, but that's probably the safest bet

Wojtek, ah you are here too, that is convenient.

it's convenient but then we have discussion here and on github and we are rehashing this issue again ;-)

> and in case of other clients it boils down to having issue with detecting `@` + nick why, we would not have an @ then

I'd say you should lock the issue :x

pep. lock down for corona issues? :D

:)

anyhow, I do not mind, I am not a beagle IM user.

just my two cents ...

> and in case of other clients it boils down to having issue with detecting `@` + nick. And enforcing "@" on all the ecosystem, introducing more places where body needs to be parsed, etc. etc. :)

@pep. I have pinned it :-)

cool

yeah, this one and http-upload got a lot of attention and complaining so it makes sense to pin them.

go to https://github.com/tigase/beagle-im/issues and observe

the issue is displayed at thet op of the list of issues in repository

never heard of pinning, what does this github language word mean? ✏

we are not enforcing it, but other clients could check for mentions not only on `\w<nick>\w` tbh, I'm not sure that incidental mentions notifications are all that great

nice

Wojtek, yeah we discussed that when ingoj opened the issue.

Some of us "use" the nick mentioning as filtering by changing nick name.

Wojtek, I don't disagree with the fact that using regex in body to match nicknames is meh. That's mostly historical though.. (damn IRC)

I don't think it's an excuse to introduce even more sigils

But that is more hacking than noob friendly usablility, of course ...

I think the whole debate around "using @ or not using @" is pointless

Agreed.

Please don't pollute the wire any more :x

let me repeat myself: "Current situation is is not ideal" :-)

Wojtek, sure

+1

Separating content from layout is important. @ is not useful here.

eevvoor, "@" is irrelevant, not "not useful" :P

@pep. btw. we do support displaying markdown messages - oh the horror ;-)

yes :)

Wojtek, you make me sad

XD

markdown and not styling, right?

gfm markdown or markdown+raw XD

(it's the same horror to me anyway, assuming you've done it the same way)

we don't allow formatting - we just try to display the intent when received because that seems to make sense

the intent?

the semantics :D

Sometiems you want to **stress** something

@ is also just a layout semantics

or @@stress@@ something

I've used `**` and `__` in the usenet days, way before markdown was a thing :-)

I'm too young for usenet :x On IRC I used * and _ sometimes (not doubled), but then again not just to emphasize, for other uses too

I've also used "/"

But IRC is what it is, I don't want to reintroduce these horrors in XMPP

It's not just IRC though, it's all text communication back to the beginning of the internet, also before my time

yes mail too

btw in mails you also mention people with @ ;)

Do you?

lots of people do

wut, why..

I don't know of any client that interprets that

(but I don't know of many clients)

no of course not

it is the humans who interpret that.

you do not have nicks in mails, it is just for structuring the paragraphs: this is imrportant for @person1, person2 and thtat for @personx

:/

Wojtek, your example in the issue is not fair as you only cite platforms that do not federate and don't have various client implementations

erm, mastodon is 3rd ;-)

ah mastodon

Well it's the only one

eevvoor - you see, I forgot email from my list, and this is just 'hoomans doing hooman things'... it's not for interpretation, just an indication. And IMHO it's better than corporate quotations with using colours and other formatting, which breaks completely when you are forcing plain-text view...

fwiw, re colors and weird formatting, I do blame email clients..

I also blame email for sure and the mess they've made with html

what are other global and popular federated networks? you could say e-mail, but many argue that e-mail is stuck in the prehistoric times and it's impossible to move it forward or introduce anything there because... it's federated

popular I don't know, but there's also Matrix. But they also have only one implementation anyway.. (:P)

they do seem to use `@` as well: https://github.com/matrix-org/matrix-doc/blob/master/specification/modules/mentions.rst ;-) (this seems a bit awful though...)

fwiw matrix also seems to have a separate representation for its html thing

Wojtek, right, so it's html, not in the text :x

I was curious how they were doing that

well, it's still in text... formatted text

seems like multi-part e-mail though

I wonter if they allow sending payloads without `body`

"body": "Hello Alice!"

where in the text?

I don't know. I don't think xhtml-im did

fallback body blah blah

Anyway I think the discussion on "@" is irrelevant. Some platforms may very well use it and some XMPP clients will reuse it for sure and that's fine. The question is how :p

> wut, why.. > I don't know of any client that interprets that FYI Of you write an @ in MS Office Mail/Outlook whatever it is called that days you can cycle through the the people on the current distributor. So they use it like Tigase/Beagle it seems.

https://signal.org/blog/signal-pins/

Summary: they intend to introduce identities that are not phone numbers (lack of which is one of the main complaints against Signal by the very market segment they target)

So they need to store a roster, but they don't want it on the server (unencrypted)

Aren’t they only hinting it for now?

If they encrypt it on the device before uploading, the user would lose access to it if they lost their device with the encryption key

Publicly hinting, and putting this effort in? It's clearly one of their priorities

Summary of their solution: SGX

Again?

They are basically storing a database of encryption keys in RAM

So they had to invent Raft-in-SGX so they could replicate across servers and data centres (otherwise all keys would be lost on server failure)

Little question of the day: In MUC Rooms, it is possible to be connected with several XMPP client with the same JID. Example: one with Gajim and one with Conversations So we can see all connected XMPP clients by user like in roster?

No.

Shared nicks in MUCs are hidden, you don't know what's behind them (unlike direct presence).

Maybe :)

Prosody includes an <item> for each joined resource

Not in the spec though

Sure, you can expose it.

Somebody could update 0045

They did, and it got published as 38 new XEPs

Thanks for your replies :)

MattJ: Well, it got published as 1 new XEP and people demanded it be split up...

I would like a clear solution, if it is possible to update it, it will be perfect!

Neustradamus_: it seems to me that there are lots of things you would like. And you expect other people to do them for you immediately and for free

MattJ: by "update" I didn't mean "reinvent from basic principles"

No, just specifiy in the XEP... And Prosody already does...

Ge0rG: XEP-0060 is a basic principle? :)

FWIW I actually agree with the split and the pubsub foundations

MattJ: yes, didn't you read the longish post by Stephen Wolfram where he derives the working principles of the universe from XEP-0060?

This problem is not new, how many years we can join a MUC Room in several XMPP clients with the same JID?

Neustradamus_: there is an article on https://wiki.xmpp.org/web/Multi-Session_Nicks that tracks implementation status

feel free to update it with facts.

Quick question: how many of you will instantly switch to signal if they get rid of phone numbers for login?

0?

Not I, because I don't believe in centralization and having a communication network relying on a single commercial entity

Lol zero?

And probably many other people who use/develop XMPP feel similarly

> Not I, because I don't believe in centralization and having a communication network relying on a single commercial entity Hmm that's understandable

Out of all XMPP users, I'm sure some may switch, sure... 0 might be a stretch. But in this channel right now? 0 may well be accurate

I don't hate Signal, it's a reasonable choice for some people who prefer different trade-offs

Ikr. The things is its borderline impossible to make my friends and family members switch to open source decentralized complicated solutions urgh

and I appreciate what they are trying to do

But trying to run a centralized service that maintains the privacy of users while providing a good UI/UX is quite hard

Agreed

They are achieving it using SGX, a magic technology invented for DRM

and multiple flaws have been found in SGX

And it is itself a proprietary technology, and the principle of DRM has been shown to be broken multiple times

It's a really neat hack, and they are inventing fun new stuff this way

But I'm not going to choose it over decentralized alternatives that are based on simpler principles

Hmm this made me rethink everything

I migrated my family (9 members of) to a new XMPP server the other day, and all it took was an email and one support call

Haha that's impressive tbh. Meanwhile my brother won't even switch to discord

MattJ: you should also say that your new server involved a custom onboarding scheme that's not published as an XEP ;)

It's published openly, and it's not my fault I'm ahead of the curve and the XEP improvements got rejected :)

MattJ: technically, it's not XMPP :P

It's still xmpp

I'm not sure how to reach that conclusion

Ge0rG, in any case, your client implements it - so when will you be removing "XMPP" from the description? :)

(and replacing it with "Modern XMPP" of course)

MattJ: I thought about "Extended XMPP" or "EX-MPP"

XXMPP?

XXX-MMP.

We all agreed extensions are bad, right? Just MPP?

MattJ: and messaging and presence are only used for spam anyway. Let's reduce to P!

it's also featuring a nice pronunciation

Is there a XEP for reporting spam/abuse in MUCs?

Other than just manually calling for mods

Zash, XEP-0224 Attention?

Heh

https://xmpp.jix.im/upload/366a70b8f42372013265023a64adf7f8efca6519/iw7tLHdSlqDMEk3g7fQ9rnZVjxAz70sfEEWFZ7qx/FB_IMG_1589990703362.jpg

jix.im, is that some kind of yax.im impersonation? :D

inb4 yax.in

Ge0rG: no it has nothing to do with yax.im

Matrix is just a layer on top of XMPP, but you don't know yet

this is deep.

2deep4u

2girl1cup?

im14andthisisdeep?

I did wonder, idly, whether one could build a connectionless HTTP binding of XMPP, and if so, how much like Matrix it would look.

By which I mean, if you pretend that an HTTP-based client is essentially always online, and connections have an enormous timeout, and hand-wave-hand-wave over presence, you'd have an initial client setup phase which looks like Oauth except SASL, and then... what?

matrix is not a real time messaging protocol but a distributed graph database...

mod_rest ?

What's that agenda link in the subject? Access Denied

That should be public

I can see it here, unauthenticated

It's the agenda for board meetings

Works here too

Then my country blocked

can you access trello.com ?

No, same

:/

Great

Can I ask which country? Or in private if you prefer

Also are you sure that's the only possible reason ✏

Ok, sent in private

Trello's support things seem useless

If you can provide more info that allow us to ensure it's indeed your IP/country that's being blocked, I'll open a ticket on their community forum.

And if nothing changes (which I'm almost certain), I'll raise that to board

I think there is nothing we can do, it's US ban

Can you dig trello.com?

I live in Latakia Syria, regime controlled, I don't know what more information to tell

They also have servers in europe apparently. That's what their dns give me from here, and from Asia they give me the US servers

https://pix.mathieui.net/o/UobYh.png well if you need the agenda, xnamed^

is there any XEP for keyboards like in Telegram bots ( https://core.telegram.org/bots#keyboards )?

I guess this might help? https://xmpp.org/extensions/xep-0439.html

thanks pep.

Hi all; IIRC MattJ is working on an update to MAM so hopefully that will be undeferred soon, but XEP-0359 is also deferred and it's required by MAM and generally being used more and more. Can we undeferr it somehow? Maybe just by issuing a LC, or is anyone planning changes to it soon?

I was thinking about using it in something, but it's just confusing to everyone when more and more of the ecosystem is using specs that say that you shouldn't use them in big red letters at the top, so it would be nice if we could change this.

I have two concerns about it right now: I (like a number of other people) strongly feel that origin-id should be removed, or a rule added that it must always match the id attribute if present

Secondly it was meant to decouple ids from MAM, but it hasn't in practice

There is no way to add an id to a stanza without archiving it if you are an archiving entity

Yah, I'm not a huge fan of it either, I just hate us relying on something that's deferred everywhere. MAM is a huge part of the ecosystem already, and you wouldn't know it if you find it by searching for "how to have archives in XMPP" or something.

I say remove Deferred? :x

This state is just useless

There the last modified date at the top, it's enough already

I disagree with removing deferred, it's very useful in general, I just think we should be careful that widely implemented and popular parts of the ecosystem actually get moved forward.

Or even if that just means having a whitelist where council decides "this is popular, it should not go to deferred even if it hasn't been modified in a while"

How is it useful?

What's the goal of deferred really

If it's only "indicating that something hasn't been updated in a while", then there's a date at the top already.

So that I'm not tempted to implement every random crappy XEP that someone submitted once and no one implemented but now it's in the list

And then that confuses everybody who doesn't understand our process

No one looks at dates.

They just scroll down the list of XEPs on the /extensions page of the website, or stumble upon them from a search.

We want to keep that list at least sort of manageable

Why would there be a whitelist of XEPs that shouldn't go in deferred. Isn't deferred supposed to indicate that a XEP hasn't been updated in a while?

Because some XEPs haven't been updated in a while but are also widely used and popular.

And those should still be in the list and we still want to encourage experimental implementations of them.

Sure, Deferred doesn't prevent a XEP from being used

I never said that it did

And it's still equivalent to Experimental

Not sure what's the issue

If you're going to make exceptions I say just remove it. (I say remove it anyway..)

The difference is that experimental says this at the top: "the protocol described herein is encouraged in exploratory implementations"

And deferred says this: "Implementation of the protocol described herein is not recommended for production systems"

We want to eventually reach that last state where we say "no one has looked at this in a while and it never took off, so probably don't do it" and council won't vote on every one, so automatic deferral is probably good.

However, council also doesn't move things forward very fast, so the way we have it setup right now it catches too many false positives and defers useful things.

So I'm just spitballing suggestions for how we could fix that.

I also proposed one

I know, and I tried to explain why I thought it was a bad idea.

Well all I hear you saying is "I don't like that it's not stated on deferred XEPs that it's still equivalent to experimental"

You'll end up having some sort of deferred state anyways, council will just have to decide when to move things to it and will forget and won't move tons of random old crap which will stay in experimental forever.

That's an easy fix

It's not still equivalent to experimental, I literally just posted why they're different.

It's experimental + time passed

No, it's not. It's "don't implement this" and experimental is "try implementing this and tell us what happens"

If you remove the time limit, then council ends up having to move to some deferred like state anyways because we want a way to say "don't implement this"

Why would time be the only factor in choosing to implement a spec, that's.. weird

(not to say stupid)

Council is not the only factor here

It doesn't have to be, that's exactly what I'm saying, we should find an alternative. Having time as one of those factors just takes weight off of councils shoulders though because they don't have to remember to double check every random experimental XEP to see if they should defer it every year or so

Message retraction was a good example for this

Somebody sent it, it got LC'd iirc, it got dropped by the author, then 3-4 years later somebody digged it up

(LC'd and refused)

Tbh I don't like our process very much. Experimental or not, XEPs are gonna change anyway, or they're gonna be changed by other XEPs (which is exactly the same to me). As a developer, Deferred doesn't give me any concrete information apart from "Somebody (possibly multiple) didn't have time to look into it".

I'd rather have rejection reasons included in specs when they've gone through LC already

rather than just leaving it in a big bag of who-knows-whats-gonna-happen-to-these

Oh yah, I definitely think it would be beneficial to have a rejection summary in the specs, that would be great. For everything else though, deferred is useful because it's important to know "Somebody didn't have time to look into it"

How is that important. Somebody did make the effort to write down their idea at least ✏

They did, and that doesn't mean the XSF should encourage implementing it. We have enough confusion without a million old XEPs that someone touched once and then never looked at again floating around with banners at the top saying "Try implementing me and see what happens"

If no one has touched it in a while and it never got popular, it makes sense to step back and not encourage it unless someone wants to pick up the slack and work on it again.

"that doesn't mean the XSF should encourage implementing it", the XSF already does. For a year after it's been promoted to Experimental

What has changed is.. time

I know, that's literally what I'm saying.

> I guess this might help? https://xmpp.org/extensions/xep-0439.html Great, what about suggestions too while typing a command, maybe we can add option to request bot commands : Prefix Description Syntax, to be used by the client, for example autocomplete nicknames and JIDs, and to send command correctly Maybe some icons

SamWhited, Yeah and then you get things like MAM as you said earlier. My feeling about a whitelist is "meh", sorry I don't have much feedback, but having an exception to the process feels weird

yah, fair enough, a whitelist would feel weird to me too

Maybe some other state between experimental and draft, or just redefine draft to be easier to edit.

We should try to kill this myths that nothing changes :)

MAM doesn't seem to fit into deferred at all, and is currently not ready for the current draft state (apparently since it's still being modified a lot and doesn't survive last calls), but it's obviously widely adopted and the ecosystem doesn't really work without it, so it seems like there should be something else for it.

"a lot" is quite relative

It changes.

Fine, it changes. Doesn't really matter if it's "a lot" or once every few years, the point still stands.

I'm no council but I could see it in draft tbh

Oh yah, personally on this particular spec I think we should just move it to draft and be done with it, but I feel the same way for carbons and a lot of other stuff

Sure

So if it doesn't fit in experimental (which council may or may not agree with, I dunno) and council doesn't think it fits in draft, I can only conclude that something needs to change.

Then when somebody(tm) figures out how to fix carbon, either fix the document, or if too many people complain then make a new one (it's the same anyway..)

xnamed^, that would depend on the client

When sending the message, the bot would state what commands it expects

The client can use this information

SamWhited, maybe that means the XSF needs to put more effort in getting these things adopted :)

pep. agreed.

The editors have been doing a good job of at least LCing stuff recently, which is great.

We can't force implementations to update their codebase instantly though, for feedback

We can sponsors things to be implemented, certainly

Anyways, I'm going back offline now, if an editor could move XEP-0359 out of deferred, however that's done, I'd appreciate it. A LC might be good on that one just to solicit more feedback and get it back to experimental.

pep.: I think depending on both, what client would expect from bot as normal message and use that information for command suggestions, the idea is to reduce typing and sending messages

I'm not sure what more you need from the bot

First thing need to tell the client this is a bot 😁

You don't actually need to know it's a bot do you

You just need to see there are preformatted answers you can use

But anyway, if you really want to know it's a bot, you can check XEP-0030 identities, https://xmpp.org/registrar/disco-categories.html#client

Not exactly I need to know if bot or not, but if has commands which can be used for suggestions

Same way of ad hoc commands

Then you can use the 0439 as I linked earlier

If you receive such payload then you know what to reply ✏

xnamed^, https://core.telegram.org/bots#commands < for something like this, use ad-hoc? And then maybe find/write a way to advertize this is the set of commands you support as a bot

Not sure if there's such a thing already

It might be weird though to use ad-hoc and also send messages

Yes, so I suggest to be new xep