XSF Discussion - 2020-04-19

just get snikket listed there

I wonder how much user meta data is stored on a matrix home server. Probably the answer will be "roughly as much as xmpp"

And afaik it is stored forever.

They have to please their investors somehow

Erm didn't Riot.im stop using Matrix? Or am I confusing with something else?

I guess you are. It is their main client.

The flagship Matrix client even.

Zash, oh sorry confused with disroot

And I can't find a client which actually uses either xep 215 or 278 to fetch sturn/turn data for A/V

Jitsi which supposedly should use Jingle Relay Nodes, does SRV look ups.

Jitsi Meet does '215

but I haven’t gotten it to actually use the results…

jonas’, Jitsi Meet is a bit too much OOB for my likings.

Movim uses a hardcoded list of stun services which almost never work...

Holger: https://github.com/processone/ejabberd/issues/3229

Neustradamus: Do you have a client that would use this?

Neustradamus: E.g. the WebRTC spec explicitly doesn't support this.

> Jitsi Meet does '215 Only extdisco:1 though. (Dunno whether Maranda uses Prosody's mod_turncredentials which supports that.)

Holger: I will search...

Holger: STUN ejabberd works with IPv6?

Neustradamus: No.

A ticket is needed too :/

https://github.com/jselbie/stunserver

Neustradamus: Someone having time to implement such stuff is needed 🙂

Holger, Metronome has mod_extdisco which supports both 1 and 2 fully (aka has support for <credentials /> queries)

Holger: Can you move my ticket in the good repository?

at least in the latest commits, also I implemented jingle relay nodes tonite.

Maranda: Ok. I'm still hoping they'll just update to extdisco:2 as I'm not aware of another client needing :1 and don't want to spam the code with :1 support just for Meet …

Holger, tbh I didn't even take Meet in consideration as on Android it looks to be not using xmpp even, it just wants some kind of URL, didn't understand how to add a xmpp account

which tells much about the UX there

Maranda, yeah, the UX is pretty amazing

you only need the URL to the meeting

Maranda: Well it's all XMPP but without roster, yes. Different use case.

The XMPP account is usually an anon account.

Holger: I have listened a lot of remaks like it, in a server case "a client supports?" and in a client case "a server supports?" ah ah

Neustradamus: Really? I have not seen a single client developer saying that. I've seen the WebRTC guys explicitly stating they don't want it despite other STUN/TURN servers supporting it.

Neustradamus: If you have a link to any STUN/TURN client dev making such a statement I'd be interested.

Holger: coturn supports it :) - https://github.com/coturn/coturn/blob/master/README.md

Neustradamus: I know that. That's good, no? Client devs interested in it could just use that.

Neustradamus: And ejabberd admins interested in offering that could just set up coturn.

Holger: unsure about the exact details of what you are proposing, and don't have the time to dig into it. However, breaking backwards compatibility of extdisco because "only Meet" does not sit well with me.

It's an older spec that we know has at least one fairly popular user. Who knows what we don't know about.

Apologies if my drive-by reading of this caused a misinterpretation of what you actually mean.

Come to think of it, why wasn't http upload made on this?

Nice thought

Not an exact fit tho

Guus: https://github.com/jitsi/jitsi-meet/issues/5786

Holger: my point is that there could be other implementations that we don't know about. Breaking backwards compatibility should be avoided where possible, especially for XEPs that have been published a long time ago.

Guus: I.e. it's just about whether I should add support for an old (5 years) version of the XEP. I'll probably just submit a PR against Meet if they don't do it themselves. Less work than adding support for that old 0215 revision to ejabberd.

Guus: Sure, I'm all on your side when it comes to keeping existing support. ejabberd still does mam:tmp and all following revisions. But do you really implement each and every old revision of an XEP when adding a new module?

Holger: oh, no. I am fine with introducing new versions. I was under the impression you were suggesting incompatible changes to the xep without a namespace bump.

Guus: Ah, no not at all.

My bad, carry on. 😁

I'm implementing the current revision of the XEP which is 5 years old. My problem is just that Meet doesn't support this revision yet.

Openfire has a dead simple plugin that supported what Meet needed a couple of years ago.

Nothing after that

Iirx

Guus: that's a very broad comment which I generally disagree with, the backward compatibility one. https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 (I thought there were more revisions)

We publish standards. People using them must be able to rely on some form of stability.

pep., could you clarify with what exactly you disagree with?

keeping backwards compat forever and never deprecating anything because !!!

"some implementations might.."

Holger, do you have an idea what damencho means with "port the changes" in https://github.com/jitsi/jitsi-meet/issues/5786#issuecomment-610921989

That's not the point, is it? The point is that if you implement X.Y, X.Y should not change such that you no longer interoperate, as I understand it. Which I agree with.

I got the impression that they had a fork of the Prosody plugin

It's fine to deprecate support for X.Y, but any X.Y implementations should interop

pep., I don't see anything wrong with keeping backwards compat for a long period of time, as long as it does not block certain breaking changes in newer protocol versions

Kev: well that's the point, if you always keep backwards compat then the protocol never evolves

A given version of the protocol doesn't evole, that's kinda the point.

what Kev says

I'm fine with breaking changes, but not without a new namespace to ensure that the old version remains unchanged/compatible

If you want to do new backwards-incompatible things, you signal that.

then you get things like "we should do bind2 / im-next"

Guus: Actually, usually a feature flag is preferable to a ns bump, IMNSHO.

there's still a migration in between that's required

Kev: sure. Some kind of identifying thing suffices

flow: > Holger, do you have an idea what damencho means with "port the changes" in https://github.com/jitsi/jitsi-meet/issues/5786#issuecomment-610921989 Yes what Zash says, they have a fork of the Prosody module. The upstream module supports the current revision, their fork (and their client-side code) doesn't.

I'm not discussing the fact that a version doesn't change obviously. just discussing the fact that x.y doesn't have to be backwards compat with x.y+1 (note that XEPs are not following semver)

Holger, so its about changing the code to match the xep, and not bumping the xep to match the code, right?

flow: Yes.

pep., obviously a namespace bumped xep protoocl is (typically) not compatible with the previous namespace protocl version

if that's includes what you are expressing with x.y+1

I'm thinking we're all pretty much mean the same

It's Sunday so we're all procrastinating to avoid family things?

I think some things changed when we introduced namespace versioning

so I somehow think we may be all on the same page of the same book but written in different languages ;) ✏

Holger, already did my obligatory bike ride with two kids in the trailer!

In the olden days, an experimental XEP just changed

flow: 👍

MattJ, <3

I guess there is a reason why this is no longer the case ✏

flow, "I have a cool idea - we could bump the namespace every time", which seemed like a good idea (not saying it was/wasn't), but I think this also subtly shifted expectations about an experimental XEP

and possibly even contributed to the laziness about advancing them

MattJ, part of the problem is that we have to staging area for breaking changes

That used to be experimental, is basically what I'm saying

which is why it's called experimental, and that status has the description text it has

Right, and I think it shouldn't be experimental because there is a reason why this is longer the case, while I think we should introduce a staging area

I think in hindsight (which nobody had back then), introducing namespace versioning should have been bundled with other changes

there is no reason we can't have stable namespaces (urn:xmpp:foo:1) and staging namespaces (urn:xmpp:foo:2-snapshot)

Namespace "versioning" is also misleading IMO. There is no such thing as versions in XML namespaces. Changing the number there (in an, to the XML parser, opaque string) forks all elements to be entirely different.

"Implementation of the protocol described herein is not recommended for production systems." made sense when the protocol was liable to change on the server side with no warning (same namespace)

flow, but then you can’t promote 2-snapshot to 2 without touching all pieces of software, see above

jonas’, shorthand for "namespace-based versioning", i.e. versioning the protocol by bumping the namespace

MattJ, that makes much more sense, thanks

MattJ, true, but that doesn't mean that it suddenly does not make sense to have that disclaimer for experimental

jonas’, I think a sed would be sufficient

Jitsi Meet is successful software using an experimental XEP in a production setting

flow, go and sed all existing debian packages of $client then.

jonas’, that would make no sense

Were they wrong? They haven't suffered at all, and we're discussing how to let them get away with their choice without being burnt - i.e. protecting production implementations of experimental XEPs

and if we're going to protect implementations of experimental XEPs from breaking changes, we needn't have that disclaimer

flow, but then clients which implement the logic of a :2-snapshot version which is identical to :2 are unable to talk to entities only supporting :2 for no good reason.

Yes, namespace bumps hurt - another thing that wasn't clear at the time, without implementation experience

jonas’, I wouldn't expect software using -snapshot namespaces to be shipped, or at least not to be shipped with support for this explicitly enabled

flow, that’s not how it works

otherwise, software wouldn’t implement and ship Experimental XEPs by default

because a -snapshot is for experimenting in an agile way with unstable protocol extensions

End users don't care about Experimental or not

flow, but then experimentation settles down and half a year later we figure out that this is the thing we want to use in the future

and then it gets promoted to :2

you'd never would want them to be available for end-users. otherwise you would risks XMPP reputation

and we can only learn that it works by deploying it

and then there’s a bunch of software running on the latest :2-snapshot from that half-a-year window which is locked out for no good reason

flow, I think we’d be more risking XMPP’s reputation by not having MAM, Carbons and other things which are in fluctuation rolled out ✏

> flow> so I somehow think we may be all on the same page of the same book but written in different languages ;) yes and no, it often feels like people are afraid to break anything. Not saying "break all the things!", but if there a breakage that will.make things easier/better afterwards, just do it.

jonas’, experimental xeps with a bump namespace on breaking changes policy are very different to -snapshot namespaces ✏

as other said, nobody cares about if it's called experimental or not

what matters is that the protocol identified by its namespace is interoperable.

and that is not true for -snapshot namespaces

> and if we're going to protect implementations of experimental XEPs from breaking changes, we needn't have that disclaimer I think it depends on the Experimental etc.

It's all somewhat more nuanced than the stages suggest.

jonas’1> flow, I think we’d be more risking XMPP’s reputation by not having MAM, Carbons and other things which are in fluctuation rolled out And i never said that I want to take that away

but we are obviously very bad at preparing new backwards-incomptabile versions of XEPs

flow, you did by saying that -snapshot should not be delivered

or do you honestly think that carbons in its current state wouldn’t be -snapshot?

jonas’, I think you are reading more into it than I actually said

then I must’ve completely misread 11:48:13 flow> jonas’, I wouldn't expect software using -snapshot namespaces to be shipped […] care to clarify?

jonas’, I think there could be an upper bind in time after which -snapshot gets into a stable namesapce

then everyone would know how long he has to get his favorite change into the new xep version

jonas’, proposed and "accepted" changes are staged in a -snapshot namespace for x time, after that it becomes the stable namespace

what if another change happens in x time?

does that delay the propagation of the first change to stable?

details we could discuss, but this basically mimics certain software development models

but it is obvious that it should not be possible to delay a new stable namespace forever

I’m not so sure that you can simply transfer software development models to standards/protocol development models

I think you can do, we already do namespace versioning

(obviously you can not transfer everything from one domain into another) ✏

but aren't xeps managed in a source code control system?

I think any solution based on time is naïve. We know all too well the "volunteer effect"

pep., I am always happy to hear better ideas ✏

and we already have a lot of time based policiy when managing XEPs, sure it does not work that well, but I think an imminent timeout caused me to take action once in a while ✏

Not depending on volunteers only (but paying people to work on $things) :) And that's a different but related topic I'd like to see started quickly ✏

right, we could do that too. but it is not really an argument against what I suggested

Sure

Anyway I still think people are always afraid to break anything even if that would make things better and that annoys me

I'd also like to point out that a staging area and a -snapshot namespace version could be considered similar to how RFCs are updated: 'bis' I-Ds as staging area, and some use a reserved value that is sometimes not the same value as the afterwards released RFCs for protocol version signalling ✏

hm can someone stop MattJ from bumping the namespace of the MAM XEP?

just in theory

everyone has a price

i thought experimental XEPs are totally in the hands of the Author

if he doesnt change the nature of the XEP

lovetox, council can take authorship away

and then they could either roll back or instruct the editor to hold the PR

Wasn't it to be an additional feature?

i wonder because it seems all very subjective and council members seem only to really care about XEPs they care about

tbh i haven’t been following the current mam discussions. but whether justified in this case or not; the amount of different MAM namespaces conversations currently supports is ridiculous

Daniel but nobody forces you to support these, really if you support :1 and :2 this is already very good

i hope you dont support :0 and :tmp

This is the price you pay for deploying Experimental XEPs :)

I guess paid work incentives people to support ancient tech forever

i support 0; because openfire i think

Mmm, deployment stats would be handy

Current stable Prosody does only :2 unless you go for 3rd party MAM module. Similar with Carbons.

yeah next Gajim version will only support :2

:2 is already years old

For what poezio supports it's only :2 ✏

> If the 'with' field's value is the bare JID of the archive, the server must only return results where both the 'to' and 'from' match the bare JID (either as bare or by ignoring the resource), as otherwise every message in the archive would match What's the rationale behind that in 0313?

Was that for PubSub still?

Ge0rG: I don't think so, no. Every message in your archive matches your own jid for either from or to, so searching for your own jid would be useless unless it meant something else - e.g. both to and from must match.

On a personal archive that makes sense. What about on a semi anonymous MUC?

Is 'with' even used in MUCs?

The Prosody implementation just ignores that field on MUCs

(actually because the internal field is overloaded and used for something else there)

Ge0rG: On a MUC you wouldn't be searching for the MUC's bare JID if you want a particular user, you'd be searching on full JID.

Kev: that makes sense

Maybe I should reword my question into: "the rationale for this should be added to the XEP"

Also I'm confused about that custom <flip-page/> element inside a data form. Why not a boolean field?

Wait, inside?

Cc MattJ

Not as a sibling to?

Oh, maybe yes. I'm reading the diff by flow

Still, my question remains

Because it's related to the result page, not the query?

Also what's the benefit of defining the gone error condition over just item-not-found?

Huh

Ge0rG, isn't the rationale for that in the XEP?

:)

before-/after-id selects an exclusive (excluding? words?) range?

Daniel, for the record, I haven't bumped the namespace in MAM. There are some additional features which have a new disco feature, which can only be advertised on top of the current one. So if you don't use those features, you don't need to make any changes.

MattJ: the rationale for with=account? I must have missed it

The rationale of <gone/>

MattJ: yes, there is one. But is it really useful to have?

Doesn't gone mean the JID (you're talking to) has gone away?

Is there any additional information for the client in it?

Yes

Threads, where are you?

Seems a stretch to use 'gone' for items when there's an 'item-not-found'?

<gone/> means the item used to exist, and has been purged/trimmed. If you're doing full-sync MAM, that means you lost messages, and also that you should resync the full archive to catch up.

MattJ: I need to check for two different error conditions now, but the server developers won't store all UIDs ever used anyway, so I won't ever experience that in practice.

<item-not-found/> is ambiguous, e.g. if the archive was restored from a backup

so with item-not-found you can't assume that the id was ever known to the server

Why not a custom error condition?

MattJ: but what does that knowledge give me?

Ge0rG, that resyncing the archive would potentially be a very wrong thing to do

MattJ: and that I should do what instead?

Because you'll just refetch an entire archive of messages you already have

You're the client dev, you decide :)

So I have to re-fetch the whole archive to see where the server has new data.

You can page backwards instead, or do something time-based, etc.

MattJ: but that's also what I'd do on gone.

Zash, I originally did use a custom error condition. But I'm sure there is a stronger argument for re-using existing conditions where possible.

MattJ: because you can't guarantee that I'll actually get gone as a dedicated error at all

You're right that <gone/> may be misinterpreted, so a custom condition probably does make sense

MattJ: you could help me by returning me the timestamps and IDs around the gap

MattJ: but you don't know whether my request is for before the start of the archive or for a missing message from in between

Missing messages in-between are forbidden by the XEP

So if something is missing it's missing at either the start or the end

MattJ: you can only solve that by demanding that I request an ID and the respective timestamp

MattJ: but you just said restored from archive

That implies there are missing messages in the middle

This reminds me of what I've heard of how version control things do sync

MattJ: because after the restore there will be new messages added

At some point, yes

MattJ: yes, so I don't see the point.

Well, better suggestions welcome

Otherwise I can nuke any attempt at trying to provide the client some useful information about what might be going on

MattJ: you could use the same error with an additional custom condition, but I really don't see what I can do differently in that situation

MattJ: if a leak in the middle is forbidden, you MUST NOT restore the archive from a backup that's not a complete replica at the time of the crash

differently to...? What would you do today?

Which makes backups useless

MattJ: a full sync for 7 days or some such

So you may still download 6.9d of messages you already have

MattJ: so you suggest that I go backwards from $NOW until I encounter a known message?

Ask for the last message in the archive, ???, do something with that

(the last message id/timestamp could be included in the error, as Ge0rG suggested)

Zash: the last message in the archive will be from just five minutes ago

(last and first?)

The first message in the archive will be either before or after the last message the client knows about

And that would be somehow actionable for me

Have the client send id of the last message it has, then the server replies with its own last message id, then you compute something magic with set and graph theory and then you're golden

If it's before, then there is a hole in the archive

FWIW my plan for bind-ng was to include the id of the first/last message in the archive already

I want my client to store messages in the database in roughly chronological order, because ordering a table with two years of chat history is fucking slow.

There is no way to resync that with an archive that has unknown holes.

I agree, unknown holes are the enemy and are what I'm trying to prevent (as well as useless full resyncs)

So I'm trying to give the client information that it can use, because a simple "it's not here" is not enough

And a client that doesn't need to store in chronological order will just page backwards in any case

MattJ: why not?

Because it could mean you didn't sync soon enough and you missed some messages, the archive was purged, or it was restored

Especially given that most implementations won't actually be able to tell me "your ID is too old and got wiped" anyway

Ok, so I'll remove it I guess

Maybe bind-ng can fill the gap instead

MattJ: you could make it mandatory to store all IDs forever, that would make the feature useful

Or blockchain!!!!

What Zash said

I'm not going to make that mandatory, but there are other ways to implement this

(ordered ids, for example)

MattJ: a bloom filter?

Ordered and encrypted?

Timestamp plus random salt encrypted with a private key, so that the server can reverse it?

Exactly

See, it's so easy. Make it mandatory!

Oh, also renumber all existing archives!

Oh glob

Ge0rG, no, renumbering would be too invasive

That's exactly why I didn't make it mandatory

let’s just introduce another ID :)

Also all client copies, synchronously!

High precision timestamp

MattJ: just add a way to query the size of the archive

The size doesn't really help

unless you mean time period

But I hesitate to do anything much based on timestamps

The size can be measured in days as well

Yeah, I understand that

I understand the rationale now and see how you could pull it off. But would you actually do that in prosody?

Potentially, yes, if it can be done in a sane way

But now it may just be better to replace this all with a query that returns some metadata about the archive

The first/last ids and timestamps

Even more info in the hands of clients

Summary thing?

Summary!

Or have a multi query where the client sends its last known ID and timestamp and the server just fills up

Smart servers, dumb clients!

And thus the pendulum swings

The MAM logic for matching reflected own messages is maddening already.

Daniel: > i support 0; because openfire i think Openfire has 0, 1 and 2.

Also I must filter all my local MAM ID lookups on incoming-only

Also encrypting information into the archive UID might end up with all sorts of bad effects, if done incorrectly

Weren't you the one who disliked long IDs, Ge0rG?

Zash: I still am

MattJ and I discussed / looked at Twitters snowflake (?) id stuff, which is a 64bit integer

Ge0rG/all: thanks for the feedback, I've retracted my "ok to merge" on the PR and will prep a new version this week

MattJ: Re with=account, > Maybe I should reword my question into: "the rationale for this should be added to the XEP"

> Also I'm confused about that custom <flip-page/> element inside a data form. Why not a boolean field?

I think both of those were answered, and now I'm on a mobile keyboard

The latter isn't a filter

MattJ: it's a kind of a filter.

It's not part of the criteria

MattJ: well yeah, I just wondered if it wouldn't be easier to re-use existing protocol

For with, the reason is given in the XEP

Ge0rG, that flip page thing is a bit inbetween worlds

the dataform in MAM represents the filter you request from the database

MattJ: the sentence for with doesn't even end in a full stop. I'm sure it's missing more

afterwards you specify with RSM the page settings

also "as otherwise every message in the archive would match" is not the rationale, it's just a technical explanation which doesn't enlighten why you need the feature

now flip page is not part of rsm but its also not a filter

It's the rationale

actually in a perfect world flip-page would be in the RSM XEP, but sadly its not

It's not technical, it could have not been added, and then there would be no way to search for messages with yourself

MattJ: the rationale would be "To allow querying for messages the user sent to themselves, the client needs to set the 'with' attribute to the account JID. In that case, the server MUST only return results where both the 'to' and 'from' match the bare JID (either as bare or by ignoring the resource), as otherwise every message in the archive would match."

"the bare JID of the archive" is weird at least for a MUC archive

Potentially, yeah

MattJ: feel free to quote that in the new XEP

"the bare JID of the archive" is weird at least for a MUC archive"

Ok ;)

:P

11:28:00 PM [mysql] Attempting to start MySQL app... 11:28:00 PM [mysql] Status change detected: running 11:28:02 PM [mysql] Status change detected: stopped 11:28:02 PM [mysql] Error: MySQL shutdown unexpectedly. 11:28:02 PM [mysql] This may be due to a blocked port, missing dependencies, 11:28:02 PM [mysql] improper privileges, a crash, or a shutdown by another method. 11:28:02 PM [mysql] Press the Logs button to view error logs and check 11:28:02 PM [mysql] the Windows Event Viewer for more clues 11:28:02 PM [mysql] If you need more help, copy and post this 11:28:02 PM [mysql] entire log window on the forums

how can i solve it?

Hey. I'm not sure that this is the right place for that. More context needed.

Can someone refresh my memory, I remember discussion regarding "messages with UI elements", like having buttons appear in the chat and sending a predefined result when clicking one of those buttons. What was the result of that discussion? Not required? Already possible with data forms?

https://xmpp.org/extensions/inbox/buttons.html ?

Syndace, basically, the result was those exact questions, to which I haven't had the energy to XEP up an answer yet.

Ah yes, exactly that

Alright thanks

There's precedent for sending dataforms in messages, tho awkward for what I was aiming for

Help getting that back on track would be appreciated

Either by figuring out if we can just shove ad-hoc commands in messages or dataforms or continue with that

continue with "that"?

I'm afraid I have to read a few XEPs before I can be of use here

Will do though, I'd really like to see that being specified

Syndace: with that protoxep*

I no longer work on the implementation I wanted that spec for

Find an excuse to do it in Snikket?

isn't there also some movement regarding a (http based) bot API?

I think those two things go together well

Yes

🤖️> The build of *thing* failed. [abort] [retry] [send angry message to author of latest change]

Threaten the author to not use their software!!!!elf!!eleventy

What you think you said. ↑ What unpaid volonteer developer hears: I will decrease your support load!!!!

Win-Win. You're not getting angry about the software anymore and happy dev can program on a flower meadow enjoying life instead of doing hated support.

After reading ad-hoc commands I feel like those are one level too high for XEP-buttons. ad-hoc works "synchronously" with IQs and specifies a full bidirectional interaction between an entity that offers a command and an entity that wants to use the command. I think for XEP-buttons we neither have fixed commands that entities could offer, nor should the button requests/responses be synchronous with IQs aka requiring both parties to be online at the same time.

I'd rather have a way to say "please display the data form in this message somewhere inline"

Syndace, study this: https://xmpp.org/extensions/xep-0045.html#requestvoice

Syndace, just put a form into a message

if a client supports showing forms he can display them

for example Gajim has a plugin that shows forms in the chat

well there must be a gotcha with that, otherwise Zash's protoxep wouldn't exist?

Tho the buttons protoxep was more about having a list of buttons

Syndace, yes, how do you represent a simple button with a form?

ah right, that

the question is why would you need to show more than one button?

Zash, simple button? like only one choice?

form's don't have any actions or such attached

if you want to choose, you can show radio buttons

even in ad-hoc those are separate

it would also trivial to add something to a form, so a client shows buttons instead of radio buttons, for single-list type

I had some text about this somewhere

hm but that makes no sense .. you have to send the form

so one challenge is buttons with forms

I am sorry, but I don't get the issue here with forms? Are we talking about yes/no buttons?

and the other challenge is specifying how the client reacts to such a form, like how the selection is responded back to the sender?

i'd say that is specified in the data form xep

i.e., you send the submit form back

Syndace, this is already all specified

we use forms everyday

then please rephrase > form's don't have any actions or such attached

flow, do or don't forms rather

hmm, "do or don't forms"?

can you give an example?

flow, I offer you a button. You click it, or you don't.

Zash, wouldn't that be just to submit the form or not?

potentially with a single boolean or text-single field?

a single FORM_TYPE

+ you can have title, description

not sure if that would work. isn't FORM_TYPE just the "namespace" of forms?

ahh ok, with more textual content, then yes

How about: A form with only hidden fields

And you want to support more than one per message

so a bot can say [abort] [retry] [cancel]

`<x xmlns="jabber:x:data" type="form"><title>Click me</title></x>`

If there are fields other than hidden you'd render it as a form and like have a Submit button on it

Oh no, not this discussion again

Data forms don't support buttons, and clients will never implement them, and it will be a usability nightmare

okay so that's why the protoxep doesn't just use data forms

MattJ, i dont know what you mean by "Buttons"

I know people here probably don't use other messengers much, but many of them have this feature (Facebook Messenger and Telegram for example)

Syndace, there was an idea about using dataforms (or anything) as payload

The idea is that it's easier to send a quick predefined response to a message by tapping a button

Syndace, basically you get a bunch of <button>s, any xml content in those get sent back in a <click> container when clicked

then you use dataforms or json or whatever

The use case is bots, where the possible responses are generally limited/fixed

MattJ why cant i choose my response from a radiobutton selection and press send?

Because clients don't (and won't) implement that

and it becomes ambiguous if a client doesn't implement forms

But they would implement buttons?

lovetox, how do you know it's a set of distinct buttons and not a form with a select dropdown?

Yes, because it's far simpler

> basically you get a bunch of <button>s, any xml content in those get sent back in a <click> container when clicked wouldn't that be enough already?

no need for data forms if we're at that point?

Syndace, for what?

To make a client display buttons and get a response when one is clicked

lovetox, are you really going to add inline data form rendering? and do you think other clients will? To this day none of the mobile clients support data forms

xep rejected by council, I've no energy to spend on that, ???, nothing

The problem im having with this is, thats is very very simple XEP that people want to extend, and then you basically add to it and add to it, until you have dataforms

Adding a list of buttons above the text entry is relatively easy compared to an arbitrary sized form containing any kind of possible widgets

agreed, I think data forms is "too flexible" here

This won't be added to, because it does just one very simple well-defined thing

until one wants to add something really simple to it

Then we reject *that*

like a multi-text field above the buttons to send text

Why reject the initial proposal?

Yes, multi-text would indeed be crazy

its perfect reasonable, why cant i type a comment before i press the button and send that with?

Another argument against forms :)

MattJ, I think someone asked for a protoxep that described the form approach, as comparison, and that's not been submitted and probably won't be unless someone (not me) does it

Even if a very simple use-case emerges that is later added to the buttons-only XEP, that's still much better than forms and all the confusion that comes with forms edge cases

`<button><{my-special-protocol}payload/></button>`

there you go

I think the people who rejected it probably have no experience of other messengers or why this feature is useful

Data forms would be pointless bloat

MattJ, even if you specified a restricted subset to be treated as a simple button?

If I ever do need to implement this feature, I just intend to implement the protoXEP

If you did do that... *why?**

It's 100% pointless, and makes more work

Dunno, reuse of namespaces

marc: are you still maintaining XEP-0401? Can you ping me (JID/email as your prefer: sam@samwhited.com) if so? I'd like to chat about integrating it with IBR2

because i already have a dataforms impl

The point of the buttons is that they map to plaintext user responses

(or xml)

lovetox, you already have a pubsub impl too, so... let's use that!

And an ad-hoc iml!

How about we ship a disco#items ad-hoc command list in a message?

SamWhited, as an active user of a "variant" of XEP-0401, I'm interested in such discussions

If all commands are single-step and form-less then they're equivalent to buttons

MattJ, Zash: I just submitted a revamp of 0389 which I would appreciate feedback on (it's a little messy and hard to follow right now, so I may make a few changes before it gets merged): https://github.com/xsf/xeps/pull/929

If marc and I chat I'll CC you into any discussions

Ge0rG might also be interested (and now mentioned)

Was just chatting with him too :)

👍️

I want to figure out the maintenance status of XEP-0401 first and if we can get the existing PRs merged, then maybe we can start a discussion about adding an IBR2 challenge type into it

i already see the horror, people write bots that send you buttons to lead you step by step through some process

lovetox, like memberbot? :)

Imagine getting buttons for quick answers instead of typing yes / no

im not question that there is a good use case for the button xep

voting is definitly one

i just fear, because all clients implement it, for what people abuse it then

It will be awesome!

how do forms prevent abuse?

How do you prevent *any* abuse?

SamWhited: you've seen https://yaxim.org/blog/2020/01/31/yaxim-0-dot-9-9-fosdem-edition/ and the video in it?

Syndace, forms are made so you can make .. Forms of any size and kind

so i dont see how you can abuse such a non specific use case

Ge0rG: TL;D(Watch)?

SamWhited: live demo of cross client 0401 with ASCII art QR code

wait can you not search the mail archives

inpossiburu

Syndace: download the mbox file and search locally

Maybe we should kindly ask gmane. Is that still a thing?

found it by checking the dates surrounding the protoxep last update date

but meh 😀

Hm

https://logs.xmpp.org/council/ is also a good resource

love how the presence spam is logged

Hysterical raisins.

You should see the stuff logged by the original MUC logger implementation.

> lovetox> i already see the horror, people write bots that send you buttons to lead you step by step through some process yeah imagine people doing ad-hoc (bot commands) with buttons! just like they're doing bot commands with messages atm :p not sure if it'd be an improvement.

Syndace, there's a checkbox somewhere that lets you hide joins and parts

Also everyone can see in a MUC what you voted

joins and parts? 😀 oh boy, my internet language is lacking behind

like, mail thread joins/parts? ✏

oooh joins as in presence spam, sorry

yeah it has to be pretty clear that votes are public, otherwise we're gonna get more users complaining we're not respecting their privacy!!

Maybe one can send the answer as PM

Syndace, https://logs.xmpp.org/council/2018-12-12?p=h#2018-12-12-f53055662532f142

thanks, still busy with the mails tho

the feedback on the mailing list seems to mainly be "but then people want more features and we end up with data forms!!11!!"

tedd had some actual feedback regarding details about the behaviour but that's really just missing because the protoxep is minimal and could be added without a lot of discussion

Zash: I also take advice for representing buttons in my terminal

Syndace: ^

don't

buttons are just a more convenient way to send a fixed string

:P

not supposed to be funny 😀

tab completion

that's what the spec is currently

there, done

true

Zash: that's meh

1: yes 2: no 3: maybe >

you'd need to indicate first that you're doing buttons somehow (which one of the 3 last buttons messages that were sent?)

that's one of the behavioural details that are missing. but that's not a reason to reject the protoXEP, the rule would probably be as simple as "only do button stuff for the most recent message"

though i give you it's a common issue in terminal stuff. So tab won't fix it

[yes] [no] [abstain] [maybe] [nuke it from orbit]

Syndace: why?

simplicity and telegram 😀

you also don't have to worry then to which button-message an answer corresponds

ah so we're Inn the business of reproducing telegram now? :)

yep!

I thought it was WhatsApp and Slack until today

Are we not in the business of absorbing everything from every communications protocol?

in*

> do we wanrt to open the can of worms what the "last message" is again? 🙂 is "last message" an issue for XMPP?

is it the one I sent with this device or any device? maybe? even though that's been specified iirc?

also for buttons only incoming messages are relevant

sure, my message above was just answering yours directly ✏

ok, that was a quote from the discussion on buttons

ah ok

Done reading. I think most of the feedback is fine and can be fixed/clarified in the protoXEP. The question of Simple Buttons vs. data forms is obviously the biggest issue, but I think by clarifying that the buttons are just shortcuts to send quick fixed-string responses that question can also be answered.

I'd dearly love to see this pushed through

I'm starting to realise that a big problem is people not understanding the use case

As council member and author of that protoxep, I would be happy to see that move forward as well.

So in a MUC i press the yes button and then i see my "yes" appear as reflection in the MUC

does that work this way also in Telegram?

Maybe rename it "Quick Replies" and then the use case will be more obvious?

Sure. Probably wasn't smart to imply some specific UI for it.

Android has this as a feature. It's some AI driven nonsense that tries to predict what you might say based on the context of the message, but if they have an API to manually manipulate them I can see Conversations or something setting them to use ones included in the messgae instead.

MattJ: that's not impossible. I wouldn't be surprised though if somebody proposed something slightly more advanced such as "send reply and attached justification" (dumb exemple) and it got refused because "you can already do 90% of this via xxx"

FWIW I was also studiying the stuff in Slack which is somewhat more advanced than just quick replies.

SamWhited: yeah that's quite annoying

pep., arbitrary text string reactions?

suggested reactions?

Zash: suggested replies

pep. I really like the idea, it just never has any useful replies for me

A rename sounds sensible

often I fear I'm gonna hit them instead of what I want to do

the question how this works in muc is justified though

What's the question?

Is the answer Hats?

Usually

no

Hats XEP is nearing the top of my XEP to do queue!

everyone can see your "votes" lovetox noted

(THREAD: Hats) Hats + Security labels + filtering. Get to it!

I feel like I've asked this before, but "Hats"?

Yes, like they can see anything you type

yeah probably no question here actually

SamWhited: maybe known as "badges" in other systems?

MattJ: yes but "votes are private!!" something

SamWhited, https://xmpp.org/extensions/xep-0317.html

ahh, right

Thanks

SamWhited: but we've had them way longer, just nobody really cared until now to implement and finish the XEP

pep.: I really don't understand

yeah no, private votes are not covered by this and that's it

So would you really do that kind of quick reply thing in MUCs then?

Why not?

It Depends™

If you do voting, then closed voting would need to work differently.

is this really supposed to be quick replies? is the string actually sent as a message or what?

Yes

uh

Unless you wanna replace the response with some XML blob

See? Nobody understands

Please don't replace the response with some XML blob. I also didn't understand before, but now that I do I really like the idea and want to use it :)

Zash, maybe it would be worth sticking some in-reply-to stanza-id just because?

but clients that don't support buttons wouldn't set in-reply-to

MattJ: just that I don't see the use-case at all

(Hat: Council) Can someone please write a XEP about `<in-reply-to by="jid" id="stanza-id"/>` ?

If there were some in-reply-to stanza-id or <thread> or attach-to or something clients could special case it to just show a counter on the original message or something if they support it, which would be nice

votes made a bit more sense

Syndace, there is the Slack-like use-case which is also interesting, where you maybe don't want/need to send a text message, but perform some action

Adhoc/forms might work better for that

so a simple "this button was clicked" payload is enough to trigger the bot to do something

Zash, too many taps

You can't ad-hoc on a message

Also this has a nice fallback behavior for clients that don't support adhoc/forms (which I suspect is almost none). In Mcabber I can happily type "yes" or whatever.

MattJ: Offer of ad-hoc commands in a message?

SamWhited, exactly

OR A MUD

Just use Emoji reactions for voting

GO WEST

Zash, and then it gets way more complicated, and what if the command is multi-step? Ugh.

Zash, YES

MUD in XMPP when

eta, over a decade ago

You had to be there

You were eaten by a grue.

(the heck is a grue?)

I made a MUC^Hd component, it was great

MattJ, is the source somewhere

MattJ, I will run this

It's around, but likely too embarrassing to point you to

I kind of lost track, MattJ do you want the slack-like use-case to be covered or did you just note that it exists?

MattJ, I have a low tolerance

or a high one

Syndace, should probably be separate from the quick reply thing

whichever it is :P

I think it was hosted on some forge that no longer exists

ah

But I think I have it in backups

Zash agreed

Syndace, Zash: but it's the same UI...

and essentially all the same business rules

Just one sends a body, and one does not

MattJ: Not quite, not if you wanna clone it. Slack lets you do full on forms IIRc.

I don't particularly want to clone it

hmm, one needs client support that probably has to be discovered, the other is just plain text

No, it doesn't have to be discovered if you're fine with it being optional

and discovery in a MUC would be a nightmare

So this is an optional shortcut thing

(and that's exactly how it gets used in Slack)

okay I'm not farmiliar with the slack buttons, can you give an example please?

e.g. a PR notification in a MUC has a merge button. But you could also open the link and click the merge button

`<action>[ <body/> | <{jabber:x:data}/> | the json xep </>`

I guess I can just not implement it in poezio then, that simplifies UX issues.

ah, so quick link-click in addition to quick response? 😀

unless now you add a different meaning to it

or wait, merging is quite specific and probably needs slack to "understand" git?

Syndace, it's just handled by bots

Slack doesn't understand any of this

The bot posts a message in a Slack room, when a user clicks a button, the bot gets informed about that

(there is some fancier stuff too, but my goal is not to fully clone Slack)

you could define the quick response button to send /merge or !merge on click, if the bot understands that?