-
pep.
jonas’: also who would set that critical flag?
-
Seve
ralphm: yes, as far as I remember dwd was the most on the loop regarding MLS
-
jonas’
pep., sender, and the spec would mandate it
-
flow
jonas’, I wonder what the motivation and envisioned use case behind that is?
-
Ge0rG
flow: if you encounter an element that's marked as critical, and that you don't know, you engage the airbags and make the computer explode
-
jonas’
flow, it came up the other day, and I’m still playing with the thought. It *could* be useful for entities to (a) learn that the peer who received the message cannot deal with an extension and (b) for the recipient of such a message (generalized, could be an IQ or a presence or whatever) to show an indiciator, e.g. if it’s received in the context of a 1:1 conversation
-
ralphm
What about multi-device, offline, etc. It feels a bit like the urgent flag in e-mail.
-
jonas’
ralphm, especially in multi-device it’s useful in replacement of feature discovery. It is kind of a "ask for forgiveness instead of permission" thing
-
ralphm
Won't every extension be marked critical?
-
ralphm
Especially if at some point large corps world be forced to federate using XMPP.
-
Zash
Kind of a large shift to move away from ignoring what you don't understand
-
ralphm
This
-
ralphm
IMNSHO client and feature/protocol developers should include fallback behaviour in their design.
-
lovetox
whats the fallback for chatstates? :D
-
lovetox
i think its a failed approach to say everything needs a fallback
-
Kev
The fallback for chatstates is not rendering chatstates.
-
Kev
The fallback for most things is ignoring them.
-
lovetox
there are things where it makes sense, and there are things where the client just ignores it
-
Kev
In fact the majority of fallbacks are probably ignoring them.
-
lovetox
yeah if you consider ignoring a fallback, then im fine with it
-
Kev
Ignoring as a fallback has worked well for most things over the last 20 years.
-
lovetox
i agree, although im not on board for 20 years :D
-
Kev
Nor me, only 18.
-
lovetox
regarding having a body fallback for reactions, i can see both sides, but i find it unlikely that somebody uses a legacy client for very important conversations and depends on that new clients send a body fallback
-
Daniel
Seeing how very much annoying message correction is in clients that don't support it (looking at you Dino) I can only imagine that reactions with fallbackswill be much much more annoying once a popular client has support for it and people start using it
- Kev reacts to Daniel > Seeing how very much annoying message correction is in clients that don't support it (looking at you Dino) I can only imagine that reactions with fallbackswill be much much more annoying once a popular client has support for it and people start using it with a 👍
- Kev reacts to Daniel > Seeing how very much annoying message correction is in clients that don't support it (looking at you Dino) I can only imagine that reactions with fallbackswill be much much more annoying once a popular client has support for it and people start using it with a ❤
-
Kev
It's taking the piss, but it's genuinely going to be like that.
-
Kev
And assuming we take this as the new model, it'll continue long beyond when 'all' clients support reactions.
-
Kev
And, of course, you'll never be able to stop supporting old versions, or it'll start getting worse again.
- Kev reacts to Kev > It's taking the piss, but it's genuinely going to be like that. with a 🎇
- Kev reacts to Kev > It's taking the piss, but it's genuinely going to be like that. with a 🎆
- Zash reacts to /me reacts to /me reacts to /me reacts to /me with :chutulu:
-
ralphm
Doesn't look too bad.
-
ralphm
But another choice for reactions could be not having a fallback body. Yes, non-supporting clients wouldn't see anything. Not sure if that's bad.
-
MattJ
How much do we care about non-supporting clients?
-
MattJ
Even if a client wanted to not show the fallback, but otherwise not show reactions, that would be trivial to implement
-
flow
I think it is. But I also believe the whole discussion is mostly pointless as we do not have any implementation experience, is heavily dependent on the personal taste and you can't forbid clients developers to add a fallback body (even if the XEP states so)
-
flow
also I think it is trivial for clients to not show fallback bodies if the XEP is designed right
-
flow
i.e. messages with fallback bodies will also have that special extension element
-
ralphm
Indeed
-
lovetox
flow, fallback is for clients that dont get updated
-
lovetox
a client who gets updated, just ignores evey message that has the reactions namespace
-
lovetox
no need for fallback
-
larma
a client that gets updated can also produce the fallback body on their side for incoming messages. So if you'd want to annoy pidgin users, you could have libpurple render the reactions fallback body even if there was none transmitted on the wire 😉
-
Ge0rG
> also I think it is trivial for clients to not show fallback bodies if the XEP is designed right This is the minimum I will insist on. But given that, I think that annoying legacy users is less bad than silently leave them out of the conversation.
-
Kev
I think the 'legacy users' thing is fallacious.
-
Kev
If I implement this this afternoon, everyone in here other than me is a 'legacy user', and will start getting annoyed.
-
Ge0rG
Kev: yaxim is implementing the suggested quoting format for a year or so now, and emoji on their own line will be displayed in 6x size. Nobody complained about that so far.
-
Kev
And then I start developing a new extension that does similar things, so do the same, and not only is everyone else a legacy user, but there's no spec yet for them to implement. So if we believe that it would be 'annoying' to 'legacy users', that means it's annoying to current users too.
-
Kev
If we believe it's not annoying, that's a different thing (I don't currently see how it could not be annoying, but it would be a different thing).
-
Ge0rG
Even if we believe that it's annoying, we need to weigh between the right of legacy users to participate and the importance of reactions. That said, annoying them is probably a very good way to increase the pressure on the respective client authors.
-
Zash
It can easily backfire into "xmpp sucks" tho
-
Kev
Assuming that users have control over which clients they use is fine in the personal-user-on-the-Internal case (mostly), but not in many other environments, but you still might get interactions with other clients. I don't believe we can reasonably have a policy of "Inconvenience people who don't support feature X so that they upgrade".
-
Zash
Kev "This message is encrypted but your client sucks, switch or GTFO"
-
Kev
Idd.
-
Ge0rG
Kev: my humble opinion is that it's much more annoying to learn, by accident, after the fact, that you missed out on a part of the conversation.
-
Kev
Maybe <fallback>...</fallback> is the least bad option. It's a bootstrap problem for now, but in the future we could rely on it.
-
Zash
How is that different from body?
-
Kev
It doesn't get shown in the conversation flow automatically.
-
Ge0rG
what would <fallback> be good for, then?
-
Ge0rG
For the clients that implement the XEP but decide to not show the actual reaction?
-
Ge0rG
So they can show the ugly <fallback> text element?
-
Kev
Assuming <fallback/> to be be a generic fallback mechanism, It'd allow a client to alert the user that there are parts of the content that they're missing.
-
Kev
While not flooding the log with potentially more meaningless reactions than there is message content.
-
Zash
Like EME but generic?
-
Kev
EME?
-
Zash
Encrypted Message Eeeeeh, what was it?
-
Ge0rG
Element?
-
Zash
XEP-0380: Explicit Message Encryption
-
Kev
Kinda, ish.
-
Zash
So a generic variant of this would be "this message won't make sense unless you understand feature x"
-
Kev
Or, rather, "If you don't understand this element, the meaning is X", I think.
-
Ge0rG
Would that be just a tag, or an actual text element?
-
Kev
But I could imagine a client saying "This chat contains content that Swift can't render: 5000 messages containing [An emoji reaction to a previous message]" or something, where the [] has come from the <fallback/>.
-
Ge0rG
also it can't be inside of the non-supported element, because it's not supported, so it needs to be outside, and have the ns of the non-supported element as an attribute, because a message can contain multiple fallbacks.
-
Ge0rG
It's all a PITA
-
Zash
How is saying that better than just having some fallback "foo reacted with bar" in body?
-
Kev
Zash: Because that's one message rendered in an info box somewhere outside the log, rather than 5000 messages inside the message box preventing you seeing the 1000 messages of content.
-
Ge0rG
Speaking of which. This MUC mostly contains irrelevant presence changes.
-
Zash
And can't you do this any time you see a message with unknownnamespaces?
-
Kev
Ge0rG: Yes. Imagine if your client was showing each of those to you because it didn't understand they were presence updates, it'd be insufferable.
-
Kev
Zash: You can warn that there's content you don't understand, but not know whether it's interesting content, or what the content represents.
-
Ge0rG
Kev: my client does understand that, but fails to aggregate / hide them in a meaningful way.
-
Kev
Talk to your client author :)
-
Ge0rG
Because apparently, you can't force client authors to do useful things.
-
Kev
Swift hides updates other than joins/parts, and even those it condenses in a (hopefully) smart way.
-
Kev
And even that I'm considering dropping.
-
Ge0rG
It's something that's actually useful for admins, and for when you are writing a message to somebody who just disappeared.
-
Kev
The join/part, yes. Which is why I'm only considering dropping, rather than having actually done so :)
-
Zash
Someone who was recently active (sent messages) leaving is more interesting than some idling and then dropping out, right?
-
Kev
Depends entirely on the situation, I think.
-
Kev
(But may well be)
-
Ge0rG
Only show the leave if a message by that person is visible on screen. The next logical step is to add a presence indicator to that message.
-
Ge0rG
Which is actually something I plan to add to yaxim
-
Ge0rG
You could also add a notification bubble if you mention an occupant that's offline.
-
ralphm
Also want to note that MIX would handle these cases better in sense that you can choose to not subscribe or display certain streams.
-
Ge0rG
Like the Emoji Reactions stream?
-
ralphm
I can see a use for an explicit fallback element. That said, I'm also curious about stanzas with more than one namespaced element.
-
ralphm
Ge0rG: I suppose that would be a very decent idea. However, then you'd have different handling for one-on-one chats.
-
ralphm
I meant presence and join/leave above.
-
Ge0rG
Yeah, got that.
-
ralphm
I don't think doing reactions over pubsub for one-on-one chats is a good idea. But then, having both options for MIX would suck.
-
rion
Isn't xmpp going to fully migrate to pubsub?
-
ralphm
So I'm tempted to say: don't put reactions in a separate stream. Unless we have multiple streams that are delivered with regular message stanzas, and I don't like that either.
-
ralphm
rion: going strong since 2004
-
ralphm
Eh 2002 I mean
-
ralphm
rion: seriously though, something like reactions is likely considered part of a conversation. Taking it "out" by using pubsub events breaks that.
-
ralphm
Unlike, say, a stream of code commits, the tunes you are playing, or news flashes.
-
ralphm
If I'd work on Slack, for example, I'd build something that takes such streams out of the channel, and move them to the side bar.
-
ralphm
However, you could still start a thread from such notifications, e.g. causing the commit with comments to become embedded in the chat stream.
-
ralphm
Or allow the user the choice at least.
-
pep.
Guus, it wasn't intended. I don't think we'll migrate the logs, meh
-
pep.
I'll move to the new url
-
pep.
All URIs in 0372 references pubsub are incorrect right? They use "?node=" and not "?;node="✎ -
pep.
All URIs in 0372 referencing pubsub are incorrect right? They use "?node=" and not "?;node=" ✏
-
ralphm
Hmm, yes, that's wrong
-
pep.
https://github.com/xsf/xeps/pull/810 here
-
ralphm
Query parameters should be separated by semicolons, too, not ampersands.
-
pep.
As in, "xmpp:fdp.shakespeare.lit?;node=fdp/submitted/stan.isode.net/accidentreport&item=ndina872be" should be "xmpp:fdp.shakespeare.lit?;node=fdp/submitted/stan.isode.net/accidentreport;item=ndina872be" ?
-
pep.
will do
-
pep.
done
-
lovetox
that semicolon after the ? looks weird
-
lovetox
sure this is right?
-
Ge0rG
0372 is weird.
-
Ge0rG
my gut feeling would be that the question mark is not needed, but what do I know of URIs.
-
ralphm
Yeah, your gut feeling is wrong. Without question mark, there's no query component.
-
ralphm
lovetox: the position before the first semicolon is for an action. Without action, eg. when pointing to a node (or item within), that position is empty.
-
lovetox
ah, thanks
-
sex www.realamater.com
www.realamater.com
-
sex realamater
https://www.realamater.com
-
sex realamater
ralphm Alex Alex Alex Alex Alex Alex Alex
-
sex realamater
Alex
-
Ge0rG
https://twitter.com/matrixdotorg/status/1159787827636441088 why don't we have a merch shop?
-
j.r
Hello, I'm currently developing a little XMPP admin helper app for Android and now I want to make a icon... I have an Idea involving the XMPP Logo but a) I'm not sure if I can modify it so that it fits in the Icon context and b) how I have to meantion that it's based on the XMPP Logo wich is as Wikipedia tells me under MIT... (My app is btwe under GPLv3)
-
pep.
Ge0rG, we should indeed
-
pep.
j.r, re licensing, you'd just need to mention somewhere in your COPYING file or README that you're using the XMPP logo with license XYZ and put the license there. If it's really MIT, I don't know, you'll have to copy that specific version of the license, because the copyright line is also part of the license and that makes MIT things somewhat unique
-
pep.
Also if it's MIT then you can of course reuse/modify/etc. etc.
-
j.r
pep., ok so I just have to find the license put it into my readme and I'm good to go?
-
pep.
IANAL, but that's generally how it works :)
-
pep.
Maybe it's even in the file itself. Is it an svg you got?
-
pep.
hmm no it's not in the one from xmpp.org. Too bad
-
pep.
hmm, CI for xmpp.org is borked. There's a PR to fix it: https://github.com/xsf/xmpp.org/pull/595, is anything blocking for it?
-
pep.
If it's blocking on editor(s) not having time (which I'm not blaming him for), I'll rush my application for that. Where do I send my resume again?
-
pep.
jonas’, ^