HolgerNeustradamus: Do you have a client that would use this?
HolgerNeustradamus: E.g. the WebRTC spec explicitly doesn't support this.
Holger> Jitsi Meet does '215
Only extdisco:1 though. (Dunno whether Maranda uses Prosody's mod_turncredentials which supports that.)
NeustradamusHolger: I will search...
NeustradamusHolger: STUN ejabberd works with IPv6?
HolgerNeustradamus: No.
NeustradamusA ticket is needed too :/
Neustradamushttps://github.com/jselbie/stunserver
HolgerNeustradamus: Someone having time to implement such stuff is needed 🙂
MarandaHolger, Metronome has mod_extdisco which supports both 1 and 2 fully (aka has support for <credentials /> queries)
eevvoorhas left
NeustradamusHolger: Can you move my ticket in the good repository?
Marandaat least in the latest commits, also I implemented jingle relay nodes tonite.
HolgerMaranda: 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 …
MarandaHolger, 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
Marandawhich tells much about the UX there
jonas’Maranda, yeah, the UX is pretty amazing
jonas’you only need the URL to the meeting
HolgerMaranda: Well it's all XMPP but without roster, yes. Different use case.
HolgerThe XMPP account is usually an anon account.
werdanhas left
NeustradamusHolger: 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
HolgerNeustradamus: 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.
HolgerNeustradamus: If you have a link to any STUN/TURN client dev making such a statement I'd be interested.
etahas left
etahas joined
NeustradamusHolger: coturn supports it :)
- https://github.com/coturn/coturn/blob/master/README.md
HolgerNeustradamus: I know that. That's good, no? Client devs interested in it could just use that.
HolgerNeustradamus: And ejabberd admins interested in offering that could just set up coturn.
j.rhas joined
mukt2has left
bearhas joined
adiaholic_has left
adiaholic_has joined
mukt2has joined
jubalhhas left
bearhas left
andrey.ghas left
lovetoxhas left
archas left
archas joined
mukt2has left
mukt2has joined
eevvoorhas joined
j.rhas left
j.rhas joined
alexishas left
alexishas joined
jubalhhas joined
lovetoxhas joined
Nekithas left
jubalhhas left
mukt2has left
pdurbinhas left
etahas left
etahas joined
GuusHolger: 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.
GuusIt's an older spec that we know has at least one fairly popular user. Who knows what we don't know about.
GuusApologies if my drive-by reading of this caused a misinterpretation of what you actually mean.
bearhas joined
ZashCome to think of it, why wasn't http upload made on this?
GuusHolger: 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.
HolgerGuus: 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.
mukt2has joined
HolgerGuus: 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?
GuusHolger: 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.
HolgerGuus: Ah, no not at all.
GuusMy bad, carry on. 😁
HolgerI'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.
GuusOpenfire has a dead simple plugin that supported what Meet needed a couple of years ago.
GuusNothing after that
GuusIirx
pep.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)
GuusWe publish standards. People using them must be able to rely on some form of stability.
edhelashas left
flowpep., could you clarify with what exactly you disagree with?
lovetoxhas left
pep.keeping backwards compat forever and never deprecating anything because !!!
pep."some implementations might.."
flowHolger, do you have an idea what damencho means with "port the changes" in https://github.com/jitsi/jitsi-meet/issues/5786#issuecomment-610921989
KevThat'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.
ZashI got the impression that they had a fork of the Prosody plugin
KevIt's fine to deprecate support for X.Y, but any X.Y implementations should interop
bearhas left
flowpep., 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
pep.Kev: well that's the point, if you always keep backwards compat then the protocol never evolves
KevA given version of the protocol doesn't evole, that's kinda the point.
flowwhat Kev says
GuusI'm fine with breaking changes, but not without a new namespace to ensure that the old version remains unchanged/compatible
KevIf you want to do new backwards-incompatible things, you signal that.
pep.then you get things like "we should do bind2 / im-next"
KevGuus: Actually, usually a feature flag is preferable to a ns bump, IMNSHO.
pep.there's still a migration in between that's required
GuusKev: sure. Some kind of identifying thing suffices
edhelashas joined
Holgerflow:
> 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.
pep.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)
flowHolger, so its about changing the code to match the xep, and not bumping the xep to match the code, right?
xsfhas left
Holgerflow: Yes.
flowpep., obviously a namespace bumped xep protoocl is (typically) not compatible with the previous namespace protocl version
flowif that's includes what you are expressing with x.y+1
flowso I somehow think we me be all on the same page of the same book but written in different languages ;)✎
GuusI'm thinking we're all pretty much mean the same
HolgerIt's Sunday so we're all procrastinating to avoid family things?
MattJI think some things changed when we introduced namespace versioning
flowso I somehow think we may be all on the same page of the same book but written in different languages ;) ✏
flowHolger, already did my obligatory bike ride with two kids in the trailer!
MattJIn the olden days, an experimental XEP just changed
flowI guess there was a reason why this is no longer the case✎
Holgerflow: 👍
jonas’MattJ, <3
flowI guess there is a reason why this is no longer the case ✏
MattJflow, "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
DebXWoodyhas left
MattJand possibly even contributed to the laziness about advancing them
flowMattJ, part of the problem is that we have to staging area for breaking changes
MattJThat used to be experimental, is basically what I'm saying
MattJwhich is why it's called experimental, and that status has the description text it has
flowRight, 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
MattJI think in hindsight (which nobody had back then), introducing namespace versioning should have been bundled with other changes
flowthere is no reason we can't have stable namespaces (urn:xmpp:foo:1) and staging namespaces (urn:xmpp:foo:2-snapshot)
jonas’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.
MattJ"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)
jubalhhas left
jonas’flow, but then you can’t promote 2-snapshot to 2 without touching all pieces of software, see above
MattJjonas’, shorthand for "namespace-based versioning", i.e. versioning the protocol by bumping the namespace
jonas’MattJ, that makes much more sense, thanks
flowMattJ, true, but that doesn't mean that it suddenly does not make sense to have that disclaimer for experimental
flowjonas’, I think a sed would be sufficient
MattJJitsi Meet is successful software using an experimental XEP in a production setting
jonas’flow, go and sed all existing debian packages of $client then.
flowjonas’, that would make no sense
MattJWere 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
MattJand if we're going to protect implementations of experimental XEPs from breaking changes, we needn't have that disclaimer
jonas’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.
MattJYes, namespace bumps hurt - another thing that wasn't clear at the time, without implementation experience
flowjonas’, I wouldn't expect software using -snapshot namespaces to be shipped, or at least not to be shipped with support for this explicitly enabled
jonas’flow, that’s not how it works
jonas’otherwise, software wouldn’t implement and ship Experimental XEPs by default
flowbecause a -snapshot is for experimenting in an agile way with unstable protocol extensions
ZashEnd users don't care about Experimental or not
jonas’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
mukt2has left
jonas’and then it gets promoted to :2
flowyou'd never would want them to be available for end-users. otherwise you would risks XMPP reputation
jonas’and we can only learn that it works by deploying it
jonas’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
jonas’flow, I think we’d be more risking XMPP’s reputation by not having MAM, Carbons and other things which are in fluctuation rolled ou✎
jonas’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 ✏
flowjonas’, experimental xeps a bump namespace on breaking changes are very different to -snapshot namespaces✎
pep.> 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.
flowjonas’, experimental xeps with a bump namespace on breaking changes policy are very different to -snapshot namespaces ✏
flowas other said, nobody cares about if it's called experimental or not
flowwhat matters is that the protocol identified by its namespace is interoperable.
flowand that is not true for -snapshot namespaces
Kev> 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.
KevIt's all somewhat more nuanced than the stages suggest.
flowjonas’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
flowbut we are obviously very bad at preparing new backwards-incomptabile versions of XEPs
jonas’flow, you did by saying that -snapshot should not be delivered
jonas’or do you honestly think that carbons in its current state wouldn’t be -snapshot?
flowjonas’, I think you are reading more into it than I actually said
jonas’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?
flowjonas’, I think there could be an upper bind in time after which -snapshot gets into a stable namesapce
flowthen everyone would know how long he has to get his favorite change into the new xep version
mukt2has joined
flowjonas’, proposed and "accepted" changes are staged in a -snapshot namespace for x time, after that it becomes the stable namespace
jonas’what if another change happens in x time?
jonas’does that delay the propagation of the first change to stable?
flowdetails we could discuss, but this basically mimics certain software development models
flowbut it is obvious that it should not be possible to delay a new stable namespace forever
jonas’I’m not so sure that you can simply transfer software development models to standards/protocol development models
flowI think you can do, we already do namespace versioning
flow(obviously you can not do everything from one domain into another)✎
flow(obviously you can not transfer everything from one domain into another) ✏
flowbut aren't xeps managed in a source code control system?
pep.I think any solution based on time is naïve. We know all too well the "volunteer effect"
flowpep., I am always happer to hear different better ideas✎
flowpep., I am always happy to hear better ideas ✏
flowand we already have a lot of time based policiy when managing XEPs, sure it does not work that well, but I think an immiment timeout caused me to take action once in a while✎
pep.Not depending on volunteers only (but paying people to work on $things) :) And that's a different topic I want to expand on quickly✎
flowand 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 ✏
pep.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 ✏
flowright, we could do that too. but it is not really an argument against what I suggested
pep.Sure
pep.Anyway I still think people are always afraid to break anything even if that would make things better and that annoys me
flowI'd also like to point out that a staging area and a -snapshot 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✎
flowI'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 ✏
jubalhhas joined
mukt2has left
bearhas joined
andrey.ghas joined
lovetoxhas joined
mukt2has joined
Maxhas left
Maxhas joined
lovetoxhas left
bearhas left
jubalhhas left
nycohas left
nycohas joined
pdurbinhas joined
nycohas left
nycohas joined
pdurbinhas left
Jeybehas joined
bearhas joined
LNJhas left
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
goffihas joined
mukt2has left
LNJhas joined
DebXWoodyhas joined
debaclehas left
Maxhas left
Maxhas joined
adiaholic_has left
adiaholic_has joined
bearhas left
lovetoxhas joined
Chobbeshas joined
lovetoxhm can someone stop MattJ from bumping the namespace of the MAM XEP?
lovetoxjust in theory
Chobbeshas left
Danieleveryone has a price
lovetoxi thought experimental XEPs are totally in the hands of the Author
lovetoxif he doesnt change the nature of the XEP
jonas’lovetox, council can take authorship away
jonas’and then they could either roll back or instruct the editor to hold the PR
ZashWasn't it to be an additional feature?
lovetoxi wonder because it seems all very subjective and council members seem only to really care about XEPs they care about
Danieltbh 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
mukt2has joined
lovetoxDaniel but nobody forces you to support these, really if you support :1 and :2 this is already very good
lovetoxi hope you dont support :0 and :tmp
ZashThis is the price you pay for deploying Experimental XEPs :)
adiaholic_has left
pep.I guess paid work incentives people to support ancient tech forever
Danieli support 0; because openfire i think
ZashMmm, deployment stats would be handy
ZashCurrent stable Prosody does only :2 unless you go for 3rd party MAM module. Similar with Carbons.
lovetoxyeah next Gajim version will only support :2
Ge0rG> 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?
Ge0rGWas that for PubSub still?
KevGe0rG: 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.
neshtaxmpphas left
Ge0rGOn a personal archive that makes sense. What about on a semi anonymous MUC?
ZashIs 'with' even used in MUCs?
ZashThe Prosody implementation just ignores that field on MUCs
jubalhhas joined
Zash(actually because the internal field is overloaded and used for something else there)
rionhas left
rionhas joined
mukt2has left
KevGe0rG: 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.
bearhas joined
Ge0rGKev: that makes sense
lorddavidiiihas left
Ge0rGMaybe I should reword my question into: "the rationale for this should be added to the XEP"
Ge0rGAlso I'm confused about that custom <flip-page/> element inside a data form. Why not a boolean field?
ZashWait, inside?
Ge0rGCc MattJ
ZashNot as a sibling to?
lorddavidiiihas joined
krauqhas left
Ge0rGOh, maybe yes. I'm reading the diff by flow
Ge0rGStill, my question remains
krauqhas joined
ZashBecause it's related to the result page, not the query?
Ge0rGAlso what's the benefit of defining the gone error condition over just item-not-found?
eevvoorhas left
ZashHuh
Jeybehas left
Jeybehas joined
lovetoxhas left
mukt2has joined
MattJGe0rG, isn't the rationale for that in the XEP?
MattJ:)
Zashbefore-/after-id selects an exclusive (excluding? words?) range?
nycohas left
MattJDaniel, 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.
Ge0rGMattJ: the rationale for with=account? I must have missed it
MattJThe rationale of <gone/>
Ge0rGMattJ: yes, there is one. But is it really useful to have?
ZashDoesn't gone mean the JID (you're talking to) has gone away?
Ge0rGIs there any additional information for the client in it?
MattJYes
Ge0rGThreads, where are you?
ZashSeems a stretch to use 'gone' for items when there's an 'item-not-found'?
MattJ<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.
Ge0rGMattJ: 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.
MattJ<item-not-found/> is ambiguous, e.g. if the archive was restored from a backup
bearhas left
MattJso with item-not-found you can't assume that the id was ever known to the server
ZashWhy not a custom error condition?
Ge0rGMattJ: but what does that knowledge give me?
MattJGe0rG, that resyncing the archive would potentially be a very wrong thing to do
Ge0rGMattJ: and that I should do what instead?
MattJBecause you'll just refetch an entire archive of messages you already have
MattJYou're the client dev, you decide :)
Ge0rGSo I have to re-fetch the whole archive to see where the server has new data.
nycohas joined
MattJYou can page backwards instead, or do something time-based, etc.
jubalhhas left
Ge0rGMattJ: but that's also what I'd do on gone.
MattJZash, I originally did use a custom error condition. But I'm sure there is a stronger argument for re-using existing conditions where possible.
Ge0rGMattJ: because you can't guarantee that I'll actually get gone as a dedicated error at all
MattJYou're right that <gone/> may be misinterpreted, so a custom condition probably does make sense
mukt2has left
Ge0rGMattJ: you could help me by returning me the timestamps and IDs around the gap
mukt2has joined
Ge0rGMattJ: but you don't know whether my request is for before the start of the archive or for a missing message from in between
MattJMissing messages in-between are forbidden by the XEP
MattJSo if something is missing it's missing at either the start or the end
Ge0rGMattJ: you can only solve that by demanding that I request an ID and the respective timestamp
Ge0rGMattJ: but you just said restored from archive
Ge0rGThat implies there are missing messages in the middle
ZashThis reminds me of what I've heard of how version control things do sync
Ge0rGMattJ: because after the restore there will be new messages added
MattJAt some point, yes
Ge0rGMattJ: yes, so I don't see the point.
MattJWell, better suggestions welcome
MattJOtherwise I can nuke any attempt at trying to provide the client some useful information about what might be going on
Ge0rGMattJ: 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
Ge0rGMattJ: 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
MattJdifferently to...? What would you do today?
Ge0rGWhich makes backups useless
Zashmumbles something about pointer to previous message something something linked list
Ge0rGMattJ: a full sync for 7 days or some such
MattJSo you may still download 6.9d of messages you already have
Ge0rGMattJ: so you suggest that I go backwards from $NOW until I encounter a known message?
thshas left
ZashAsk for the last message in the archive, ???, do something with that
MattJ(the last message id/timestamp could be included in the error, as Ge0rG suggested)
Ge0rGZash: the last message in the archive will be from just five minutes ago
MattJ(last and first?)
Ge0rGThe first message in the archive will be either before or after the last message the client knows about
Ge0rGAnd that would be somehow actionable for me
ZashHave 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
jubalhhas joined
Ge0rGIf it's before, then there is a hole in the archive
MattJFWIW my plan for bind-ng was to include the id of the first/last message in the archive already
Ge0rGI 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.
Ge0rGThere is no way to resync that with an archive that has unknown holes.
Jeybehas left
Jeybehas joined
MattJI agree, unknown holes are the enemy and are what I'm trying to prevent (as well as useless full resyncs)
MattJSo I'm trying to give the client information that it can use, because a simple "it's not here" is not enough
Ge0rGAnd a client that doesn't need to store in chronological order will just page backwards in any case
Ge0rGMattJ: why not?
MattJBecause it could mean you didn't sync soon enough and you missed some messages, the archive was purged, or it was restored
Ge0rGEspecially given that most implementations won't actually be able to tell me "your ID is too old and got wiped" anyway
MattJOk, so I'll remove it I guess
MattJMaybe bind-ng can fill the gap instead
Ge0rGMattJ: you could make it mandatory to store all IDs forever, that would make the feature useful
ZashOr blockchain!!!!
Ge0rGWhat Zash said
MattJI'm not going to make that mandatory, but there are other ways to implement this
MattJ(ordered ids, for example)
Ge0rGMattJ: a bloom filter?
Ge0rGOrdered and encrypted?
Ge0rGTimestamp plus random salt encrypted with a private key, so that the server can reverse it?
MattJExactly
Ge0rGSee, it's so easy. Make it mandatory!
Ge0rGOh, also renumber all existing archives!
ZashOh glob
jonas’Ge0rG, no, renumbering would be too invasive
adiaholic_has left
adiaholic_has joined
MattJThat's exactly why I didn't make it mandatory
jonas’let’s just introduce another ID :)
Ge0rGAlso all client copies, synchronously!
ZashHigh precision timestamp
Ge0rGMattJ: just add a way to query the size of the archive
MattJThe size doesn't really help
MattJunless you mean time period
MattJBut I hesitate to do anything much based on timestamps
Ge0rGThe size can be measured in days as well
Ge0rGYeah, I understand that
Ge0rGI understand the rationale now and see how you could pull it off. But would you actually do that in prosody?
MattJPotentially, yes, if it can be done in a sane way
MattJBut now it may just be better to replace this all with a query that returns some metadata about the archive
MattJThe first/last ids and timestamps
MattJEven more info in the hands of clients
ZashSummary thing?
MattJSummary!
Ge0rGOr have a multi query where the client sends its last known ID and timestamp and the server just fills up
Ge0rGSmart servers, dumb clients!
ZashAnd thus the pendulum swings
Ge0rGThe MAM logic for matching reflected own messages is maddening already.
GuusDaniel:
> i support 0; because openfire i think
Openfire has 0, 1 and 2.
DebXWoodyhas left
Ge0rGAlso I must filter all my local MAM ID lookups on incoming-only
DebXWoodyhas joined
j.rhas left
bearhas joined
Jeybehas left
Jeybehas joined
j.rhas joined
Ge0rGAlso encrypting information into the archive UID might end up with all sorts of bad effects, if done incorrectly
ZashWeren't you the one who disliked long IDs, Ge0rG?
Ge0rGZash: I still am
ZashMattJ and I discussed / looked at Twitters snowflake (?) id stuff, which is a 64bit integer
lovetoxhas joined
Jeybehas left
Jeybehas joined
jubalhhas left
Jeybehas left
Jeybehas joined
lovetoxhas left
Jeybehas left
Jeybehas joined
MattJGe0rG/all: thanks for the feedback, I've retracted my "ok to merge" on the PR and will prep a new version this week
Mikaelahas left
Mikaelahas joined
Jeybehas left
Jeybehas joined
Ge0rGMattJ: Re with=account,
> Maybe I should reword my question into: "the rationale for this should be added to the XEP"
Ge0rG> Also I'm confused about that custom <flip-page/> element inside a data form. Why not a boolean field?
eevvoorhas joined
MattJI think both of those were answered, and now I'm on a mobile keyboard
MattJThe latter isn't a filter
Ge0rGMattJ: it's a kind of a filter.
MattJIt's not part of the criteria
lovetoxhas joined
Ge0rGMattJ: well yeah, I just wondered if it wouldn't be easier to re-use existing protocol
MattJFor with, the reason is given in the XEP
lovetoxGe0rG, that flip page thing is a bit inbetween worlds
lovetoxthe dataform in MAM represents the filter you request from the database
Ge0rGMattJ: the sentence for with doesn't even end in a full stop. I'm sure it's missing more
lovetoxafterwards you specify with RSM the page settings
Ge0rGalso "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
lovetoxnow flip page is not part of rsm but its also not a filter
MattJIt's the rationale
lovetoxactually in a perfect world flip-page would be in the RSM XEP, but sadly its not
MattJIt's not technical, it could have not been added, and then there would be no way to search for messages with yourself
Ge0rGMattJ: 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."
Ge0rG"the bare JID of the archive" is weird at least for a MUC archive
MattJPotentially, yeah
Ge0rGMattJ: feel free to quote that in the new XEP
MattJ"the bare JID of the archive" is weird at least for a MUC archive"
MattJOk ;)
Ge0rG:P
j.rhas left
Mikaelahas left
Mikaelahas joined
Jeybehas left
Zashhas left
Jeybehas joined
Zashhas joined
Jeybehas left
Jeybehas joined
Mikaelahas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
Jeybehas left
Jeybehas joined
karoshihas left
karoshihas joined
Nekithas joined
j.rhas joined
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
Mikaelahas left
Mikaelahas joined
Jeybehas left
Jeybehas joined
Mikaelahas left
Mikaelahas joined
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
jubalhhas joined
lovetoxhas left
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
lorddavidiiihas left
Jeybehas left
Jeybehas joined
lovetoxhas joined
Jeybehas left
Jeybehas joined
alexishas left
mukt2has left
!XSF_Martinhas left
!XSF_Martinhas joined
Jeybehas left
Jeybehas joined
Maxhas left
Maxhas joined
lovetoxhas left
pdurbinhas joined
goffihas left
Jeybehas left
Jeybehas joined
pdurbinhas left
mukt2has joined
alexishas joined
alexishas left
alexishas joined
marchas left
marchas joined
Marandahas left
Marandahas joined
Marandahas left
Marandahas joined
mukt2has left
serge90has joined
Marandahas left
Jeybehas left
Jeybehas joined
serge90has left
serge90has joined
serge90has left
serge90has joined
Marandahas joined
mukt2has joined
Marandahas left
Marandahas joined
Marandahas left
werdanhas joined
Marandahas joined
serge90has left
serge90has joined
dhtghhas joined
dhtgh11: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
dhtghhow can i solve it?
Jeybehas left
Jeybehas joined
serge90has left
serge90has joined
mukt2has left
mukt2has joined
serge90has left
ZashHey. I'm not sure that this is the right place for that. More context needed.
serge90has joined
dhtghhas left
Jeybehas left
Jeybehas joined
jubalhhas left
mukt2has left
lovetoxhas joined
serge90has left
serge90has joined
Jeybehas left
serge90has left
Jeybehas joined
serge90has joined
mukt2has joined
debaclehas joined
SamWhitedhas joined
SyndaceCan 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?
ZashSyndace, basically, the result was those exact questions, to which I haven't had the energy to XEP up an answer yet.
jubalhhas joined
SyndaceAh yes, exactly that
serge90has joined
SyndaceAlright thanks
ZashThere's precedent for sending dataforms in messages, tho awkward for what I was aiming for
ZashHelp getting that back on track would be appreciated
ZashEither by figuring out if we can just shove ad-hoc commands in messages or dataforms or continue with that
!XSF_Martinhas left
!XSF_Martinhas joined
Syndacecontinue with "that"?
SyndaceI'm afraid I have to read a few XEPs before I can be of use here
SyndaceWill do though, I'd really like to see that being specified
ZashSyndace: with that protoxep*
serge90has left
mukt2has left
serge90has joined
typikolhas joined
mukt2has joined
typikolhas left
waqashas joined
Jeybehas left
Jeybehas joined
serge90has left
serge90has joined
werdanhas left
Jeybehas left
Marchas left
Jeybehas joined
jubalhhas left
serge90has left
MattJI no longer work on the implementation I wanted that spec for
serge90has joined
ZashFind an excuse to do it in Snikket?
Syndaceisn't there also some movement regarding a (http based) bot API?
SyndaceI think those two things go together well
MattJYes
werdanhas joined
moparisthebesthas left
Zash🤖️> The build of *thing* failed.
[abort] [retry] [send angry message to author of latest change]
serge90has left
marchas left
serge90has joined
jubalhhas joined
!XSF_MartinThreaten the author to not use their software!!!!elf!!eleventy
ZashWhat you think you said. ↑
What unpaid volonteer developer hears: I will decrease your support load!!!!
marchas joined
!XSF_MartinWin-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.
serge90has left
serge90has joined
marchas left
marchas joined
serge90has left
serge90has joined
serge90has left
serge90has joined
karoshihas left
karoshihas joined
serge90has left
serge90has joined
alexishas left
Jeybehas left
serge90has left
Jeybehas joined
serge90has joined
serge90has left
serge90has joined
Jeybehas left
Jeybehas joined
serge90has left
serge90has joined
SyndaceAfter 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.
SyndaceI'd rather have a way to say "please display the data form in this message somewhere inline"
emushas left
emushas joined
serge90has left
serge90has joined
ZashSyndace, study this: https://xmpp.org/extensions/xep-0045.html#requestvoice
pdurbinhas joined
lovetoxSyndace, just put a form into a message
lovetoxif a client supports showing forms he can display them
lovetoxfor example Gajim has a plugin that shows forms in the chat
Syndacewell there must be a gotcha with that, otherwise Zash's protoxep wouldn't exist?
ZashTho the buttons protoxep was more about having a list of buttons
ZashSyndace, yes, how do you represent a simple button with a form?
Syndaceah right, that
lovetoxthe question is why would you need to show more than one button?
flowZash, simple button? like only one choice?
Zashform's don't have any actions or such attached
lovetoxif you want to choose, you can show radio buttons
Zasheven in ad-hoc those are separate
lovetoxit would also trivial to add something to a form, so a client shows buttons instead of radio buttons, for single-list type
ZashI had some text about this somewhere
lovetoxhm but that makes no sense .. you have to send the form
Syndaceso one challenge is buttons with forms
flowI am sorry, but I don't get the issue here with forms? Are we talking about yes/no buttons?
Syndaceand the other challenge is specifying how the client reacts to such a form, like how the selection is responded back to the sender?
serge90has left
krauqhas left
krauqhas joined
flowi'd say that is specified in the data form xep
serge90has joined
flowi.e., you send the submit form back
lovetoxSyndace, this is already all specified
lovetoxwe use forms everyday
Syndacethen please rephrase
> form's don't have any actions or such attached
Zashflow, do or don't forms rather
flowhmm, "do or don't forms"?
flowcan you give an example?
Zashflow, I offer you a button. You click it, or you don't.
flowZash, wouldn't that be just to submit the form or not?
flowpotentially with a single boolean or text-single field?
j.rhas left
Zasha single FORM_TYPE
Jeybehas left
Jeybehas joined
Zash+ you can have title, description
flownot sure if that would work. isn't FORM_TYPE just the "namespace" of forms?
flowahh ok, with more textual content, then yes
ZashHow about: A form with only hidden fields
serge90has left
serge90has joined
ZashAnd you want to support more than one per message
ZashIf there are fields other than hidden you'd render it as a form and like have a Submit button on it
MattJOh no, not this discussion again
serge90has left
lorddavidiiihas joined
serge90has joined
MattJData forms don't support buttons, and clients will never implement them, and it will be a usability nightmare
Syndaceokay so that's why the protoxep doesn't just use data forms
lovetoxMattJ, i dont know what you mean by "Buttons"
MattJI know people here probably don't use other messengers much, but many of them have this feature (Facebook Messenger and Telegram for example)
ZashSyndace, there was an idea about using dataforms (or anything) as payload
MattJThe idea is that it's easier to send a quick predefined response to a message by tapping a button
ZashSyndace, basically you get a bunch of <button>s, any xml content in those get sent back in a <click> container when clicked
Marandahas left
Zashthen you use dataforms or json or whatever
MattJThe use case is bots, where the possible responses are generally limited/fixed
lovetoxMattJ why cant i choose my response from a radiobutton selection and press send?
MattJBecause clients don't (and won't) implement that
MattJand it becomes ambiguous if a client doesn't implement forms
lovetoxBut they would implement buttons?
bearhas left
Zashlovetox, how do you know it's a set of distinct buttons and not a form with a select dropdown?
MattJYes, because it's far simpler
Syndace> 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?
Syndaceno need for data forms if we're at that point?
ZashSyndace, for what?
SyndaceTo make a client display buttons and get a response when one is clicked
MattJlovetox, 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
Zashxep rejected by council, I've no energy to spend on that, ???, nothing
lovetoxThe 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
MattJAdding a list of buttons above the text entry is relatively easy compared to an arbitrary sized form containing any kind of possible widgets
Syndaceagreed, I think data forms is "too flexible" here
pdurbinhas left
MattJThis won't be added to, because it does just one very simple well-defined thing
serge90has left
lovetoxuntil one wants to add something really simple to it
MattJThen we reject *that*
lovetoxlike a multi-text field above the buttons to send text
MattJWhy reject the initial proposal?
serge90has joined
MattJYes, multi-text would indeed be crazy
lovetoxits perfect reasonable, why cant i type a comment before i press the button and send that with?
MattJAnother argument against forms :)
Shellhas joined
ZashMattJ, 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
SyndaceEven 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
MattJI think the people who rejected it probably have no experience of other messengers or why this feature is useful
MattJData forms would be pointless bloat
ZashMattJ, even if you specified a restricted subset to be treated as a simple button?
MattJIf I ever do need to implement this feature, I just intend to implement the protoXEP
MattJIf you did do that... *why?**
MattJIt's 100% pointless, and makes more work
ZashDunno, reuse of namespaces
SamWhitedmarc: 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
lovetoxbecause i already have a dataforms impl
MattJThe point of the buttons is that they map to plaintext user responses
Syndace(or xml)
MattJlovetox, you already have a pubsub impl too, so... let's use that!
ZashAnd an ad-hoc iml!
ZashHow about we ship a disco#items ad-hoc command list in a message?
MattJSamWhited, as an active user of a "variant" of XEP-0401, I'm interested in such discussions
ZashIf all commands are single-step and form-less then they're equivalent to buttons
serge90has left
serge90has joined
SamWhitedMattJ, 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
SamWhitedIf marc and I chat I'll CC you into any discussions
ZashGe0rG might also be interested (and now mentioned)
SamWhitedWas just chatting with him too :)
Zash👍️
SamWhitedI 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
lovetoxi already see the horror, people write bots that send you buttons to lead you step by step through some process
Zashlovetox, like memberbot? :)
ZashImagine getting buttons for quick answers instead of typing yes / no
lovetoxim not question that there is a good use case for the button xep
lovetoxvoting is definitly one
jubalhhas left
lovetoxi just fear, because all clients implement it, for what people abuse it then
Ge0rGIt will be awesome!
Syndacehow do forms prevent abuse?
ZashHow do you prevent *any* abuse?
serge90has left
Ge0rGSamWhited: you've seen https://yaxim.org/blog/2020/01/31/yaxim-0-dot-9-9-fosdem-edition/ and the video in it?
serge90has joined
lovetoxSyndace, forms are made so you can make .. Forms of any size and kind
lovetoxso i dont see how you can abuse such a non specific use case
SamWhitedGe0rG: TL;D(Watch)?
Ge0rGSamWhited: live demo of cross client 0401 with ASCII art QR code
serge90has left
serge90has joined
Jeybehas left
waqashas left
Jeybehas joined
werdanhas left
Syndacewait can you not search the mail archives
Zashinpossiburu
serge90has left
serge90has joined
Mikaelahas left
Mikaelahas joined
Ge0rGSyndace: download the mbox file and search locally
Ge0rGMaybe we should kindly ask gmane. Is that still a thing?
Syndacefound it by checking the dates surrounding the protoxep last update date
Syndacebut meh 😀
ZashHm
Zashhttps://logs.xmpp.org/council/ is also a good resource
Syndacelove how the presence spam is logged
ZashHysterical raisins.
ZashYou should see the stuff logged by the original MUC logger implementation.
xeckshas left
xeckshas joined
pep.> 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.
goffihas joined
serge90has left
ZashSyndace, there's a checkbox somewhere that lets you hide joins and parts
waqashas joined
serge90has joined
lovetoxAlso everyone can see in a MUC what you voted
Nekithas left
Nekithas joined
Syndacejoins and parts? 😀 oh boy, my internet language is lacking behind
Syndacethe feedback on the mailing list seems to mainly be "but then people want more features and we end up with data forms!!11!!"
Syndacetedd 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
pep.Zash: I also take advice for representing buttons in my terminal
pep.Syndace: ^
Syndacedon't
Syndacebuttons are just a more convenient way to send a fixed string
pep.:P
Syndacenot supposed to be funny 😀
serge90has left
Zashtab completion
Syndacethat's what the spec is currently
Zashthere, done
Syndacetrue
pep.Zash: that's meh
serge90has joined
Syndace1: yes
2: no
3: maybe
>
pep.you'd need to indicate first that you're doing buttons somehow (which one of the 3 last buttons messages that were sent?)
Yagizahas left
Syndacethat'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"
pep.though i give you it's a common issue in terminal stuff. So tab won't fix it
Zash[yes] [no] [abstain] [maybe] [nuke it from orbit]
pep.Syndace: why?
Syndacesimplicity and telegram 😀
Syndaceyou also don't have to worry then to which button-message an answer corresponds
pep.ah so we're Inn the business of reproducing telegram now? :)
Syndaceyep!
pep.I thought it was WhatsApp and Slack until today
ZashAre we not in the business of absorbing everything from every communications protocol?
pep.in*
serge90has left
serge90has joined
bearhas joined
Syndace> do we wanrt to open the can of worms what the "last message" is again? 🙂
is "last message" an issue for XMPP?
DebXWoodyhas left
Nekithas left
pep.is it the one I sent with this device or any device? maybe? even though that's been specified iirc?
serge90has left
serge90has joined
Syndacealso for buttons only incoming messages are relevant
Mikaelahas left
pep.sure, m'y message above was just answering yours directly✎
j.rhas joined
pep.sure, my message above was just answering yours directly ✏
Syndaceok, that was a quote from the discussion on buttons
pep.ah ok
Marandahas joined
SyndaceDone 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.
alexishas joined
alexishas left
alexishas joined
serge90has left
Jeybehas left
serge90has joined
Jeybehas joined
alexishas left
vanitasvitaehas left
vanitasvitaehas joined
alexishas joined
bearhas left
MattJI'd dearly love to see this pushed through
serge90has left
werdanhas joined
serge90has joined
MattJI'm starting to realise that a big problem is people not understanding the use case
goffihas left
ZashAs council member and author of that protoxep, I would be happy to see that move forward as well.
lovetoxSo in a MUC i press the yes button and then i see my "yes" appear as reflection in the MUC
lovetoxdoes that work this way also in Telegram?
SamWhitedMaybe rename it "Quick Replies" and then the use case will be more obvious?
ZashSure. Probably wasn't smart to imply some specific UI for it.
Jeybehas left
Jeybehas joined
SamWhitedAndroid 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.
pep.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"
ZashFWIW I was also studiying the stuff in Slack which is somewhat more advanced than just quick replies.
pep.SamWhited: yeah that's quite annoying
serge90has left
Zashpep., arbitrary text string reactions?
Zashsuggested reactions?
serge90has joined
pep.Zash: suggested replies
SamWhitedpep. I really like the idea, it just never has any useful replies for me
MattJA rename sounds sensible
pep.often I fear I'm gonna hit them instead of what I want to do
Syndacethe question how this works in muc is justified though
MattJWhat's the question?
ZashIs the answer Hats?
MattJUsually
pep.no
MattJHats XEP is nearing the top of my XEP to do queue!
pep.everyone can see your "votes" lovetox noted
Zash(THREAD: Hats) Hats + Security labels + filtering. Get to it!
SamWhitedI feel like I've asked this before, but "Hats"?
Jeybehas left
MattJYes, like they can see anything you type
Jeybehas joined
Syndaceyeah probably no question here actually
MattJSamWhited: maybe known as "badges" in other systems?
pep.MattJ: yes but "votes are private!!" something
MattJSamWhited: but we've had them way longer, just nobody really cared until now to implement and finish the XEP
lovetoxhas left
MattJpep.: I really don't understand
Syndaceyeah no, private votes are not covered by this and that's it
ZashSo would you really do that kind of quick reply thing in MUCs then?
MattJWhy not?
ZashIt Depends™
serge90has left
ZashIf you do voting, then closed voting would need to work differently.
serge90has joined
pep.is this really supposed to be quick replies? is the string actually sent as a message or what?
MattJYes
pep.uh
ZashUnless you wanna replace the response with some XML blob
MattJSee? Nobody understands
SamWhitedPlease 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 :)
MattJZash, maybe it would be worth sticking some in-reply-to stanza-id just because?
Syndacebut clients that don't support buttons wouldn't set in-reply-to
pep.MattJ: just that I don't see the use-case at all
Zash(Hat: Council) Can someone please write a XEP about `<in-reply-to by="jid" id="stanza-id"/>` ?
SamWhitedIf 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
pep.votes made a bit more sense
MattJSyndace, 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
ZashAdhoc/forms might work better for that
MattJso a simple "this button was clicked" payload is enough to trigger the bot to do something
MattJZash, too many taps
MattJYou can't ad-hoc on a message
SamWhitedAlso 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.
ZashMattJ: Offer of ad-hoc commands in a message?
MattJSamWhited, exactly
ZashOR A MUD
Ge0rGJust use Emoji reactions for voting
ZashGO WEST
MattJZash, and then it gets way more complicated, and what if the command is multi-step? Ugh.
etaZash, YES
etaMUD in XMPP when
MattJeta, over a decade ago
MattJYou had to be there
ZashYou were eaten by a grue.
serge90has left
Zash(the heck is a grue?)
MattJI made a MUC^Hd component, it was great
serge90has joined
etaMattJ, is the source somewhere
etaMattJ, I will run this
MattJIt's around, but likely too embarrassing to point you to
SyndaceI kind of lost track, MattJ do you want the slack-like use-case to be covered or did you just note that it exists?
etaMattJ, I have a low tolerance
etaor a high one
ZashSyndace, should probably be separate from the quick reply thing
etawhichever it is :P
MattJI think it was hosted on some forge that no longer exists
etaah
mukt2has left
MattJBut I think I have it in backups
SyndaceZash agreed
MattJSyndace, Zash: but it's the same UI...
MattJand essentially all the same business rules
MattJJust one sends a body, and one does not
ZashMattJ: Not quite, not if you wanna clone it. Slack lets you do full on forms IIRc.
MattJI don't particularly want to clone it
Syndacehmm, one needs client support that probably has to be discovered, the other is just plain text
MattJNo, it doesn't have to be discovered if you're fine with it being optional
MattJand discovery in a MUC would be a nightmare
MattJSo this is an optional shortcut thing
Nekithas joined
MattJ(and that's exactly how it gets used in Slack)
eevvoorhas left
Syndaceokay I'm not farmiliar with the slack buttons, can you give an example please?
MattJe.g. a PR notification in a MUC has a merge button. But you could also open the link and click the merge button
Zash`<action>[ <body/> | <{jabber:x:data}/> | the json xep </>`
pep.I guess I can just not implement it in poezio then, that simplifies UX issues.
Syndaceah, so quick link-click in addition to quick response? 😀
pep.unless now you add a different meaning to it
Syndaceor wait, merging is quite specific and probably needs slack to "understand" git?
archas left
archas joined
MattJSyndace, it's just handled by bots
MattJSlack doesn't understand any of this
MattJThe bot posts a message in a Slack room, when a user clicks a button, the bot gets informed about that
MattJ(there is some fancier stuff too, but my goal is not to fully clone Slack)
Syndaceyou could define the quick response button to send /merge or !merge on click, if the bot understands that?
MattJThis is a really simple feature that would make such a nice UX improvement
MattJYes, you could
MattJI would just rather keep the body optional, so I can make the decision as a bot author
mukt2has joined
ZashMattJ, specify reply payload as either text or Some XML Stuff™, bot decides, click sends that.
serge90has left
ZashCry in i18n for a while, done.
serge90has joined
MattJI don't even care (much) about arbitrary XML stuff, just include <button-clicked id="id-of-button"/>, and if there was a body associated with that button, include that too
MattJBut I should stop talking about buttons
pep.and now that you've mentioned hats, I'm also curious what UI for that would look like in a terminal..
waqashas left
Zashpep., mouse support exists :P
pep.Zash: what about it (and no!)
MattJ<quick-response id="id-of-response"/>
Zashwhatabouti18n?
MattJWhat about?
SyndaceI'm sorry I still don't get the difference 😕 You want to notify the bot about the click directly instead of sending a plaintext message to the chat?
MattJIsn't all this in the XEP already?
ZashYes
MattJThe XEP is what I want
MattJThe end
MattJI don't see what's so complicated
MattJClient receives a message with a list of associated shortcuts/actions/quick-replies. Client renders them potentially as buttons. Each button has an id, and an optional body text.
serge90has left
serge90has joined
Ge0rGYou could respond as a PM.
MattJIf the client supports rendering these, and the user selects one of them, then a message is generated containing the response's body text (if any) and <quick-response id="id-of-selected-response"/>
MattJWhy?
MattJWhy complicate things?
Ge0rGAlso your MAM implementation will drop the responses with no body
MattJYou're in a chat, it's a response to a message in that chat, why would you send it elsewhere?
Ge0rGBecause O(n²)
MattJ?
Ge0rGWhen everyone responds to everyone
MattJWhat?
ZashSame problem as with reactions?
MattJThat's an argument against group chats of any kind?
MattJI'm responding to you right now, is that O(n²)?
mukt2has left
Syndaceboth an id and a payload in the click response probably doesn't make sense: either you listen for the id, then the payload is pointless, or you listen for the payload, then the id is pointless
MattJBy "payload" you mean a text body, right?
Syndaceyeah
Ge0rGSyndace: it's useful if you share the room with legacy clients
MattJIt serves as a fallback for legacy clients at that point, or bots implementations that don't care for id tracking (which may be many)
mukt2has joined
MattJIf you had a voting bot for example in a meeting in a MUC, you would totally want +1/-1 to appear in the chat logs
MattJBut there are more ephemeral actions that you wouldn't care so much about
Syndaceah okay so just to have clients supporting the XEP not spam plaintext
Syndacesounds good
MattJYes
goffihas joined
pep.where is the written "+1" if your support the xep
MattJpep., ?
pep.implemented and understood by the log writer?
MattJIt's in <body>, it's understood by everyone (I hope)
serge90has left
pep.not sure I understand the following then
> ah okay so just to have clients supporting the XEP not spam plaintext
serge90has joined
pdurbinhas joined
MattJThat's for the case where there is no plaintext equivalent
MattJThe +1/-1 example was a case where you do want it to go in the logs and include a <body>
Syndaceoh okay, then my initial question still stands: why would you want _both_ and id and plaintext?
pep.so if there's a body a client must always include it?
MattJI don't see it's as entirely necessary, it just feels like a neater protocol/implementation
MattJpep., yes
Syndaceit's like you send "+1" and there is an XML element that says "this is a +1!"
MattJSyndace, an example would be if there were multiple messages and the id can be used to resolve ambiguity. But that's a stretch (because you'd need to handle non-button responses anyway)
bearhas joined
MattJBut it seems sensible to have some machine-readable semantics underneath if it's known, rather than throwing that context away
serge90has left
serge90has joined
SyndaceTo me it would feel weird if the same visible message has different effects under the hood
jubalhhas joined
Syndaceas in, a message that has both the plaintext and the id is treated differently then a message that only has the plaintext
mukt2has left
Syndaceanyway, I'm happy that we have consensus on where this XEP should be going and I'd like to see it revived with the results of that discussion
xsfhas joined
adiaholic_has left
adiaholic_has joined
MattJWhat exactly needs to change from what was previously submitted?
Jeybehas left
Jeybehas joined
MattJIf we can identity that, and who is going to write it up, we're good
MattJAnd don't have to revisit these discussions yet again in another year :)
werdanhas left
mukt2has joined
xeckshas left
xeckshas joined
Syndaceit should be renamed and the use case should be clarified, the id added and maybe clarification regarding i18n and when exactly to show buttons
pdurbinhas left
serge90has left
serge90has joined
MattJSounds good. You/Zash want to tackle it? Or I'm happy to otherwise. I'm currently in a spec-writing sprint so I can tack it onto my queue if necessary
SyndaceMaybe it's time for my first XEP, also as training for Master Key (tm)
SyndaceIf Zash doesn't want it, I would do it
ZashFeel free to take over or add yourself as co-author :)
Syndacecool 🙂
MattJExcellent :)
Tobiashas left
Zash<hat:council> I'll review it for you tho ;)
ZashMattJ, hats!
MattJComing soon
MattJAfter I finish MAM
Jeybehas left
Jeybehas joined
serge90has left
Guesthas joined
serge90has joined
adiaholic_has left
adiaholic_has joined
Guesthas left
Shellhas left
serge90has left
Jeybehas left
Jeybehas joined
serge90has joined
MarandaI'm not sure what I did change that made Movim merrily start doing 0215 queries