- paul has left
- susmit88 has joined
- debacle has left
- Wojtek has left
- daniel has left
- daniel has joined
- kusoneko has left
- kusoneko has joined
- stpeter has left
- susmit88 has left
- susmit88 has joined
- stpeter has joined
- susmit88 has left
- susmit88 has joined
- stpeter has left
- stpeter has joined
- Tobias has joined
- susmit88 has left
- susmit88 has joined
- stpeter has left
- stpeter has joined
- stpeter has left
- paul has joined
- stpeter has joined
- stpeter has left
- kusoneko has left
- kusoneko has joined
- stpeter has joined
- stpeter has left
- 3ch0 has joined
- bear has left
- 3ch0 has left
- stpeter has joined
- stpeter has left
- stpeter has joined
- bear has joined
- Tobias has left
- Tobias has joined
- stpeter has left
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- stpeter has joined
- stpeter has left
- larma has left
- stpeter has joined
- larma has joined
- debacle has joined
- stpeter has left
- larma has left
- larma has joined
- stpeter has joined
- stpeter has left
- stpeter has joined
- stpeter has left
- stpeter has joined
- eta has left
- eta has joined
- stpeter has left
- stpeter has joined
- stpeter has left
- stpeter has joined
- hotspud has left
- hotspud has joined
- vaulor has left
- SouL has left
- vaulor has joined
- SouL has joined
- stpeter has left
- Zash has left
- Zash has joined
- stpeter has joined
- stpeter has left
- stpeter has joined
- undefined has left
- stpeter has left
- undefined has joined
- stpeter has joined
- stpeter has left
- eta has left
- eta has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- stpeter has joined
- moparisthebest has left
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- eta has left
- eta has joined
- daniel has left
- daniel has joined
- dwd has joined
- undefined has left
- undefined has joined
- undefined has left
- undefined has joined
- moparisthebest has joined
- undefined has left
- undefined has joined
- undefined has left
- undefined has joined
- sonny has left
- sonny has joined
- undefined has left
-
jonas’
1) Roll Call
-
daniel
hi
-
jonas’
(sorry for the slight delay)
- undefined has joined
-
Zash
Ice cream
-
jonas’
Chips!
-
dwd
Hiya.
-
jonas’
2) Agenda Bashing
-
jonas’
fippo wants to have XEP-0338 LC’d
-
jonas’
I see no reason why not to add this to today’s agenda, so I’m going to do that
-
jonas’
anything beyond that?
-
daniel
oh yes that makes sense
-
Zash
338 is?
-
daniel
i forgot to ask for that during my round of jingle related calls
-
jonas’
XEP-0338: Jingle Grouping Framework
-
daniel
+1 for calling
-
jonas’
3) Editor’s Update - Calls in Progress - CFE for XEP-0050 (ends at 2020-06-09) - Expired/Expiring calls: - LC for XEP-0393 (ended yesterday)
-
jonas’
4) Items for voting
-
jonas’
4a) Proposed XMPP Extension: Channel Binding Capability URL: https://xmpp.org/extensions/inbox/xep-sasl-cb-types.html Abstract: This specification allows servers to annouce their supported SASL channel-binding types to clients.
-
jonas’
on-list
-
jonas’
(though at a first glance, it looks better than the other one)
-
dwd
I note this is Florian writing up his suggestion. I'm +1 on this.
-
Zash
+1
-
daniel
+1
-
jonas’
ok, it’s very massively short
-
jonas’
+1
-
jonas’
moving on
-
dwd
(I mean, this is exactly what we were all saying we were happy with last week, so...)
-
jonas’
4b) PR#949: XEP-0157: Add status-addresses registrar entry URL: https://github.com/xsf/xeps/pull/949
-
dwd
+1
-
jonas’
there was some discussion in context of this on-list, see: https://mail.jabber.org/pipermail/standards/2020-May/037443.html
-
daniel
+1
-
jonas’
I’m still not certain that this is a good place for that type of info, but it certainly doesn’t harm
-
jonas’
so +1
-
Zash
+1, assuming this is how registries work
- susmit88 has left
-
jonas’
that’s not how registries work, but we don’t have a working registry, so this is the second-best thing
-
dwd
Yes, some suggestion of whether this should be in DNS or .well-known, but it feels like putting it here is a necessary first step.
-
jonas’
Zash, do you want to change your vote based on that bit of info? ;)
-
Zash
Nah, +1 still
-
jonas’
alright
-
jonas’
4c) Decide on Advancement of XEP-0393: Message Styling URL: https://xmpp.org/extensions/xep-0393.html LC-Thread: https://mail.jabber.org/pipermail/standards/2020-May/037394.html Abstract: This specification defines a formatted text syntax for use in instant messages with simple text styling.
-
dwd
So I quite like this. But I'm aware that lots of people do not.
-
jonas’
-1, because of: - Concerns raised on the mailing list by community members about an explicit opt-in switch for the use of styling - Concerns raised on the list (by me and others) about the lack of any possible way to replace this with an updated variant (either in this or a future document) because of lack of explicit signalling - Concerns by me and others that putting "markup" in the <body/> is *not* the way to go in XMPP (this is more of a weak purity argument to some extent) - Security concerns because people will do stupid things with existing markdown parsers and the document should mention that, even though they’re not 100% compatible.
-
Zash
I agree with jonas’
-
dwd
The problem as I see it is that there are a bunch of conflicting demands around styled text in messages, and I don't think we have any clean solutions yet. This is definitely not one, either.
-
jonas’
that said, I’d like to repeat what I said in my original email: This thing did a great deal of improvement by providing rich text to flagship clients. This is good for UX. I think this was a useful intermediate step, and now we need to find a way to do this properly.
-
jonas’
but this should not be on Standards Track as is. I’d be happy to put this to Informational-Active actually.
-
jonas’
oh, and I forgot to mention another reason for -1: - Lack of explicit formal grammar to write a compliant parser.
-
dwd
Anyway - I think I'm +0 on this advancing to Draft
-
jonas’
15:11:10 Zash> I agree with jonas’ shall I record that as a seconding of my -1?
-
daniel
+1 this is standardizing something that clients in one form or another have been doing for years. this is not really in-body markdown because the formatting doesn’t get removed. it's just a suggestion on how do visually display emphasis that a user would give the text regardless. therfor it doesn’t need opt-in or opt-out
-
Zash
jonas’: sure.
-
dwd
daniel, I know it doesn't need signalling or negotiation, but I think it would be nicer if it did.
-
dwd
daniel, Also, how would you feel about Informational/Active here?
-
daniel
i'm not against adding a hint <hey-there-im-using-393/>
-
jonas’
daniel, in that case I argue that it doesn’t belong on Standards Track. It can maybe live in Informational or be moved to modernxmpp.org; just like the rules for how to use '392 with JIDs and stuff✎ -
jonas’
daniel, in that case I argue that it doesn’t belong on Standards Track. It can maybe live in Informational or be moved to modernxmpp.org (or a similar resource); just like the rules for how to use '392 with JIDs and stuff ✏
-
daniel
adding that hint probably doesn’t block it going on to draft
-
jonas’
I do not feel comfortable to approve this as (quoting XEP-0001): > A wire protocol intended to be used as a standard part of XMPP technologies. [13]
-
daniel
jonas’, i have no hard feelings regarding the track
-
SamWhited
I'm also okay with adding a "I'm using styling" hint or even a "this message isn't intended to be styled" hint, but I'd like to just state for the record that this is unnecessary bloat. Also, I took great care to make sure the grammar was well defined so that you can write a compliant parser, but there won't be a formal grammer because I don't know anything well enough tow rite one. I do feel strongly that it belongs to the standard track.
-
SamWhited
"to write", even.
-
jonas’
even Informational is stretching it IMO, but I’d accept that as a middle-ground. A non-XSF resource would be more fitting for UI things (which this is in daniels line of argument)
-
SamWhited
</author-opinion>
-
Zash
Overloading body without negotiation is problematic
-
dwd
jonas’, What on your list is blocking?
-
dwd
Zash, Overloading or hinting? (Given Daniel's observation that people literally type this stuff anyway)
- sonny has left
-
dwd
Ugh.
-
dwd
Negoation or hinting, I mean to ask.
-
Zash
dwd: Either is better that nothing
-
jonas’
dwd, I can be persuaded to accept the overloading of <body/> in this specific way if and only if an opt-in is given. The lack of formal grammar is not blocking if implementors agree that it is doable without (which is probably more something to deal with for moving to Final)
-
jonas’
if an opt-in is present, it’s also more clearly wire protocol belonging on standards track.
-
SamWhited
It will definitely never be opt-in because that defeats the whole point. The *reason* it did such a good job of getting client adoption and fixing that part of the ecosystem is that it wasn't opt-in, it was just telling you how you could apply styling to things users already do.
-
SamWhited
It could be opt-out per message, but that's all that I'd be comfortable with there.
-
jonas’
opt-in is the only thing I’m going to be comfortable with.
-
dwd
jonas’, So if it's merely hinting and not an explicit negotiation, then if I type the same stuff myself, am I *not* XMPP conformant anymore?
- sonny has joined
-
jonas’
what the opt-in would be signalling, in my mind, is: "The user observed that the message would be styled in this way before sending, e.g. by having the input UI control display styling inline."
-
jonas’
and by opt-in I mean <this-is-styling xmlns="…"/>
-
dwd
jonas’, I could see a <styled xmlns='...' active='boolean'/> around to signal whether *this* is bold or not. But given I can type it anyway, and in many clients it already will be shown bold heuristically, I can't see a problem with it being hinted rather than negotiation.
-
flow
Sorry for interrupting, but I've to run in 5m. And missed the spot when you where discussing it. One thing re 4b: I talked with pep and wondered if the form field's registry entry should include data form validation information. In particular, that the value's datatype is xs:anyURI. I think we should ideally discuss this *before* adding the registry entry, because, changing it afterwards could be considered a breaking change. Hence you may want to re-consider. I think pep (or I) would be happy to add that additional information to the registry submission.
-
jonas’
dwd, maybe that’s the misunderstanding. By opt-in, I simply mean a flag inside the <message/>. It’s not necessary to go full-blown "only do this if disco#info has something" or something like the chat session negotiation which existed somewheer.
-
dwd
jonas’, Ah, right. Gotcha.
-
jonas’
flow, does the registry support schema stuff? In that case that sounds useful, can you make a note in the PR?
-
dwd
jonas’, That would move me from +0 to +1, as well, and if it also provides a way to explicitly state that there's no styling, that'd be great, too.
-
jonas’
Zash, do you agree with that?
-
jonas’
then we’d have a clear way forward for the author
-
SamWhited
I'll add the no styling hint, but the "this is styling" hint will completely break the entire point of this and I am absolutely against adding it.
-
Zash
jonas’: A hint? Yes, that's fine with me.
-
jonas’
ok, moving on then, we have one more item on the agenda
-
dwd
SamWhited, Noted, but I think you're in the rough here.
-
jonas’
4d) Issue Last Call for XEP-0338 URL: https://xmpp.org/extensions/xep-0338.html Abstract: This specification provides an XML mapping for translating the RFC 5888 SDP Grouping Framework to Jingle
-
daniel
i don’t understand why it breaks the point
-
SamWhited
I can write it up for the millionth time, but it makes this much harder to implement, much less consistent, and generally breaks the XEP to add a "this is styling" hint.
-
Zash
daniel: same
-
jonas’
order please
-
SamWhited
But we can discuss this on list for the millionth time, sorry for taking time in the council meeting.
-
jonas’
we can continue the discussion in AOB if everyone agrees to extending the meeting time, or xsf@ or on-list
-
daniel
+1 on 4d
-
flow
jonas’, I'd have to check, but i'll be gone in a few minutes. I'd like to discuss this, as it appears we do not have a single form field in the registry which uses data form validation annotations. Likely because nobody every did it. And IMHO we should allow for it, as it's usefull information. Will add a remark to the PR. Happy to discuss this later in greater detail. bbl
-
Zash
+1 for LC
-
jonas’
+1 for XEP-0338
-
daniel
i’m expecting this have similiar outcome as the other two jingle specs we called
-
dwd
+1 to LC.
-
daniel
few but positive feedback
-
jonas’
flow, we’re still pending on Ge0rGs vote either way. Please add a note to the PR so that the Editors will defer merging and we can re-do the vote in case you find that you have to change it
-
Zash
I'm almost out of battery fyi
-
jonas’
5) Pending votes
-
jonas’
none
-
jonas’
(except Ge0rG now)
-
jonas’
6) Date of next
-
jonas’
+1w wfm
-
daniel
+1w wfm
-
dwd
+1 wwfm
-
Zash
Wfm
-
jonas’
7) AOB
-
jonas’
since Zash is out of battery and we’re running out of time, I’d like to skip this one✎ -
jonas’
since Zash is out of battery and we’re running out of time anyways, I’d like to skip this one ✏
-
dwd
Happy to.
-
jonas’
8) Ite Meeting Est
-
jonas’
thanks all
-
Zash
Thanks
-
jonas’
quick note that I sent a meeting time scheduling thing for the routing stuff (cc @ Ge0rG )
-
dwd
Thanks jonas’!
-
jonas’
SamWhited, I note you’re not in xsf@, any reason for that?
-
dwd
BTW, why would one ever block a Last Call?
-
jonas’
dwd, if it’s 90% TODO maybe?
-
SamWhited
jonas’: too noisey and distracting; happy to join temporarily if we want to have this discussion in there
-
dwd
jonas’, But you could raise that in Last Call?
-
daniel
SamWhited, i don’t understand how <styling boolean/> breaks the purpose of the XEP. it allows receiving clients to have three different modes. style everything, style everything but <styled false>; only style <styled true/>
-
jonas’
SamWhited, ok, feel free to continue the discussion here for now then
-
daniel
sending clients would have to support ever sending <styled false/>
-
daniel
if they didn’t want to
-
jonas’
dwd, sure, but ... yeah, I mean, it doesn’t make much sense to me either. I’d somehow expect LC to be editor-driven while CFE would be council-driven, but it seems to be the other way ’round
-
SamWhited
daniel: I don't actually understand the three modes
-
daniel
and just adding <styled true/> is free
-
SamWhited
What is the default if no styled=false or styled=true is present?
-
daniel
relatively
-
daniel
the receiving client can decide
-
dwd
SamWhited, The default is "Implementation defined", which is what it is now.
-
jonas’
SamWhited, "sending client doesn’t know what it’s doing, use a local user/implementation preference"
-
jonas’
while styled=true is "sending client knows what it’s doing and emphatically agrees with this being displayed fancy" and styled=false is "nope, this must not be styled ever"
- sonny has left
- sonny has joined
-
SamWhited
So now we have some clients forcing styling on, some forcing it off, and some that we just do our own thing for. From the users perspective, that's just going to be similar messages from different contacts or even the same contacts when they switch clients randomly being styled or not
-
dwd
One advantage is that if the client receives something *broken, it can know whether this is genuinely broken or just not actually styling.
-
SamWhited
If my clients default is "no styling unless styling=true" and one contact sends me "this is *styled* <styling=true>" and another sends me "this is *styled*" but they just typed it, that just looks confusing that one is styled and the other isn't.
-
dwd
SamWhited, But one of your clients might not do styling anyway, right now.
-
SamWhited
Also, how does this work in MUCs? If one user quotes a message and they apply styling=true and another replies and quotes it but their client applies styling=false, now there are two replies that represent the same quote differently
-
dwd
SamWhited, So I don't see what changes.
-
SamWhited
dwd: but they would or would not apply it equally for all messages from all contacts, muc participants, etc.
-
dwd
SamWhited, No.
-
daniel
SamWhited, well *your* client could still default to styled if there are no hints
-
jonas’
(I assume Conversations will)
-
jonas’
(at least for a transition period)
-
daniel
probably
-
SamWhited
daniel: that's even worse, now different clients that I use will have different defaults. On conversations it might default to styling=true, but when I switch over to dino it defaults to styling=false and it looks different
- sonny has left
- sonny has joined
-
jonas’
the recommendation to default to styling=true can be put in a place where client developers look for "good UX tips" *hinthint*
-
SamWhited
This adds an entire massive amount of uncertainty and possibility for breakage. Even from the sending clients perspective it adds confusion and different ways to implement things
-
jonas’
how does this add uncertainty for *sending* clients?
-
SamWhited
For example, if I click a "bold" button and it wraps the text in styling directives, I thin it's pretty obvious that styling=true should bge added to the message
-
SamWhited
However, if I just type "check out this *styling*" what should it do?
-
pep.
re flow's suggestion on 157, I'm happy to add the validation thing but I have no clue how
-
SamWhited
Should it add styling=true? Do nothing and let it be inconsistently displayed between the remote users clients?
-
jonas’
SamWhited, that depends: does your input field show it as boldface inside the input field? if so, styling=true, otherwise no.
-
jonas’
pep., I hear flow will look that up
-
dwd
jonas’, +1 on that.
-
pep.
And re 393 hint, I think that's pretty much useless
-
daniel
> SamWhited, that depends: does your input field show it as boldface inside the input field? if so, styling=true, otherwise no. +1
-
dwd
SamWhited, Your client should be expressing the user's intent.
-
pep.
Clients will just put that in the payload all the time and we're back to normal
-
dwd
pep., Isn't that OK?
-
pep.
To be back to normal?
-
moparisthebest
clients don't know the user's intent
-
Zash
I don't see how making things more explicit makes things uncertain.
-
moparisthebest
I'm certainly not going to press any 'bold' button, I'll just continue writing *like this* because that's how I've always written everything
-
pep.
moparisthebest, that's their issue, they could very well know if they allowed it in the input format
-
SamWhited
Zash: because it's not making them explicit, having a "styling=false" alone is making things more explicit, but having both is introducing even more possible states that you can't predict.
-
dwd
pep., I mean, if clients put the styling hint in all the time, that just means they're explicitly intending the message to be styled.
-
moparisthebest
I get the impression people think this XEP documents some new and exciting input format, and if so, it would indeed be bad, but it documents existing functionality in most clients across most protocols since as far as anyone can remember
-
pep.
I'm gonna repeat myself for the nth time, https://lab.louiz.org/poezio/poezio/issues/3455#note_7769 this is how you do a proper input format, and it's also possible on mobile
-
pep.
dwd, and what in the message actually is styled?
-
SamWhited
No matter what if things don't support styling obviously those will display differently. We can't fix that part except by making the styling characters something people are used to seeing anyways (which was the point of this XEP, they're already doing this anyways so that part is fine)
-
moparisthebest
email, irc, usenet, everything else, right? where you just type in your styling
-
SamWhited
Any randomization of how things are displayed on top of that is a bad thing.
-
dwd
SamWhited, So what's the randomization you're anticipating?
-
moparisthebest
many xmpp clients even already implemented this, gajim did for instance
-
moparisthebest
before it was a XEP I mean
-
pep.
moparisthebest, gajim doesn't implement 393 indeed
-
pep.
Even conversations differs slightly
-
SamWhited
dwd: I just explained it. It now matters if we have support on *both* sides of the connectio, and we have tons more states that we could be in
-
SamWhited
Eg. the situation in a MUC I just posited.
-
moparisthebest
pep., *this* always worked in gajim
-
pep.
"this"?
-
pep.
Ah "*this*"
-
moparisthebest
bolded *this*
-
pep.
So because one implementation chose stars to use bold means it's good to put in a standard?
-
pep.
And it's never ever gonna change
-
moparisthebest
not this one implementation
-
pep.
Because you have the world of god✎ -
SamWhited
Just having a way to disable it is fine, that lets us express user intent without adding a third undefined state where we're not sure what will happen
-
pep.
Because you have the word of god ✏
-
moparisthebest
pep. also a ton of other xmpp clients, most irc clients, most email clients etc etc etc
-
dwd
SamWhited, But the undefined state is the only current one in '393.
-
jonas’
SamWhited, we’ve been over this.
-
jonas’
I have seen your arguments, I just disagree with them.
-
pep.
I also disagree (but I think that's already explicit)
-
pep.
And I agree with jonas’ points for -1
-
SamWhited
dwd: sort of. Right now it's just the only state, it's not a weird in-between.
-
SamWhited
Just adding a styling=false *does* make that state more explicit, so I'm okay with that.
-
SamWhited
Adding styling=true *and* styling=false makes that middle ground confusing and undefined.
-
moparisthebest
pep., jonas’ , again it seems like you guys view this as some new protocol, instead of simply documenting what always existed without being documented
-
jonas’
moparisthebest, just because something existing doesn’t mean it’s a good thing to endorse.✎ -
pep.
this ^
-
jonas’
moparisthebest, just because something exists doesn’t mean it’s a good thing to endorse. ✏
-
jonas’
you can document all you want -- but not with XSF endorsement.
-
moparisthebest
it doesn't matter if you endorse it or not, it exists, you'll never change it
-
pep.
moparisthebest, also, nothing in what you're saying here forces you to butcher the wire format
-
moparisthebest
it'd be nice if clients would have some place to look for consistancy, rather than try to figure out what other clients do, isn't that the whole point of standards?
-
moparisthebest
this xep isn't butchering any wire format, this has always been passed over the wire like this because people type it this way
- sonny has left
- sonny has joined
-
pep.
Ok it's the same nonsense as before over again
-
jonas’
moparisthebest, we all agree that we need a force of people who can actually reason about UI choices and know things there. The XSF is (currently) not that organisation.
-
moparisthebest
again, whether the XSF officially agrees to adopt this or not, it doesn't change the fact that it's always worked this way and will continue to do so
-
moparisthebest
just makes it look dumb to not officially recognize that
-
jonas’
moparisthebest, I know that, and I’m fine with that.
-
jonas’
the first part either way
-
jonas’
the second I don’t necessarily agree with
-
moparisthebest
some of it is in fact super valuable
-
jonas’
I feel this discussion is, once more, in a dead end.
-
jonas’
and I’m going to attend to other things now, just FTR
-
moparisthebest
I've seen a lot of clients in the past, various protocols, but they *remove* the little stars for bold etc, and can accidentally change meaning
-
moparisthebest
this suggests you don't do that, which is helpful
-
SamWhited
Trying to understand peoples opinions (mostly moparisthebest, jonas’, and pep. I think): is it your opinion that it's okay for informational right now because it documents what clients are already doing and just tries to make them use more consistent rules, but only for standards track if it adds some sort of hints?
-
pep.
I'm just against it as long as there's no effort wrt. wire format. But I'm not council anyway
-
pep.
Hinting is not gonna fix much
-
jonas’
SamWhited, I think it’s not *okay* for Informational, but I *maybe* could see this as a possible middle-ground. I’m not sure about Zashes opinion on that.
-
moparisthebest
my opinion is it's a standard whether you *really wish* it wasn't or not...
-
SamWhited
pep. even if it were just informational?
-
pep.
SamWhited, what does that change
-
jonas’
pep., Standards Track is for Wire Format, Informational is "the other stuff"
- undefined has left
-
pep.
It doesn't even document what people use, it documents something that somebody wanted to force on users
-
pep.
(that is, people use some kind of markdown)
-
jonas’
I’m still not sure that Informational should be a dump for "'random' UI things documented for Instant Messaging clients which happen to use XMPP"✎ - undefined has joined
-
jonas’
I’m still not sure that Informational should be a place for "'random' UI things documented for Instant Messaging clients which happen to use XMPP" ✏
-
SamWhited
What do you mean by "force on users"?
-
moparisthebest
pep., I suspect the clients that already do this are far greater than the ones that never did...
-
SamWhited
I thought informational was explicitly for documenting what clients were already doing and that's why people mentioned it, but the XSFs spec levels never made any sense to me. I guess I should go reread 0001 or whatever
-
pep.
SamWhited, well you did specifically choose to step away from markdown to prevent devs from using markdown parsers right
-
pep.
Whereas users ask for "markdown" syntax
-
jonas’
moparisthebest, the last call didn’t bring up any except Conversations and Dino (partial implementation) I think.
-
SamWhited
pep. sort of. That was part of the decision, but also I just immitated what many clients were already doing (which wasn't markdown)
-
jonas’
moparisthebest, so I doubt that claim.
-
moparisthebest
jonas’, gajim did it before it was a XEP, still does it last time I checked
-
pep.
SamWhited, ok. Well now if I want to promote another syntax on my client anyway, I can't
-
SamWhited
pep. also, I don't think users know what markdown actually is since they keep calling this markdown anyways (though of course, if they tried to implement it it wouldn't work and they'd realize their mistake)
-
jonas’
moparisthebest, gajim does quotations and strikethrough and stuff? (I don’t use gajim)
-
SamWhited
pep. why not?
-
SamWhited
pep. isn't that the same as any other standard? We had XHTML-IM, but some people implemented it and some implemented something like this, and I think Xabber's web thing actually had its own proprietary spec, etc.
-
moparisthebest
pep., jonas’ , check out thunderbird https://burtrum.org/up/6e1978be-53dd-4036-afd0-c0ec683e19c2/open-screeny-5017.png
-
jonas’
moparisthebest, that’s not '393, it doesn’t define // or __
-
jonas’
out for real now
-
moparisthebest
then maybe it should :)
-
SamWhited
jonas’: yes, that was part of the point, everybody was doing something vaguely similar to 0393, but they all had slightly different rules. This tried to standardize those rules based on what I saw the most clients doing.
-
pep.
SamWhited, because you're not signaling yours and my users are going to receive payloads from other clients are gonna see different sigils and then complain they don't see things formatted in their client.
-
moparisthebest
jonas’, pep. , kiwi (most popular web irc client) the one freenode hosts https://burtrum.org/up/95378a1e-3720-455d-b33f-94192f69e022/open-screeny-5123.png
-
jonas’
moparisthebest, that’s not an XMPP client.
-
moparisthebest
right, again, just documenting how *everyone* used text messaging before XMPP even existed
-
pep.
SamWhited: so I have to parse supposedly meaningless text (styling) and try to convert into my markup
-
moparisthebest
that's my point
-
jonas’
you’re good at this. I need to physically step away from my XMPP client now.
-
pep.
So that I emulate other users sending my markup
-
pep.
Which is meh
-
pep.
Whether if you properly signalied on the wire where you markup is I wouldn't have to worry about clumsily parsing text
-
SamWhited
pep. I'm sorry, I didn't understand that at all, can you rephrase that first message that started "because you're not signaling yours"? Sorry
-
pep.
Styling is not being signaled. Nowhere it says "this is styling" and "what is styling in there"
- sonny has left
- sonny has joined
-
SamWhited
Right, that's what we're discussing. I got that far.
-
moparisthebest
because people don't signal that, they are just typing, remember that pep.
-
SamWhited
Wait, are you just worried that if your client doesn't support it users are going to ask you to support it?
-
pep.
moparisthebest, please stop. You don't seem to make a difference between users and clients
-
moparisthebest
pep., because with this there is no difference
-
pep.
SamWhited, I'm worried that I can't support anything else because I'll have to deal with styling anyway
-
pep.
s/worried/annoyed/
-
pep.
moparisthebest, that's where you are wrong. Or let's say we disagree
-
SamWhited
pep. why would you have to deal with styling anyways? You don't have to support it in your client if you don't want to
-
pep.
SamWhited, I do? Say I support NewMarkup (my custom format), I properly apply markup for it in the UI, and I don't apply markup for styling when receiving
-
pep.
Users would probably wonder why. What I would prefer to do is convert the received styling into NewMarkup so it also gets displayed properly
-
pep.
But that's not possible as long as styling is not signaled
-
SamWhited
pep. I don't understand how having a hint helps with that. If you support converting styling to new markup, parse the message as styling just as if you were going to display it and then convert it to your markup
-
pep.
Well the "parse the message as styling" is not really defined anywhere
-
SamWhited
Or, if there is a styling=false hint, you could not convert it (which is the hint I'm okay with adding).
-
MattJ
How about we just don't standardize this? The argument is that "users are doing it", but users are inconsistent
-
moparisthebest
pep., my question is, if I type something like *this* into my client, how would it know whether I wanted *this* to be styled or not? in fact I sometimes change my mind, here I want it styled, if I pasted some code I wouldn't want it styled, does that make sense?
-
pep.
I don't know what's styling in your message
-
SamWhited
pep. it is defined as "if you support styling, parse messages as styling"
-
pep.
SamWhited, and what is styling in your message?
-
moparisthebest
ie, the client can't know whether the user wants it styled or not, that's why it's *great* to have rules like "leave styling marks"
-
SamWhited
pep. the entire message, always.
-
pep.
"> <" is that a quote, is that an emoji
-
SamWhited
pep. that is a quote, the spec defines how you parse that. If you want it to be an emoji, that's fair, which is why I'm okay adding a styling=false hint.
-
pep.
We've been making the same arguments over two years, I'm not sure what more I can do
-
pep.
SamWhited, but then what about: "> < *foo*"
-
pep.
"*foo*" would not be parsed as bold.
- theTedd has joined
-
SamWhited
pep. why not?
-
pep.
Because you sent styling=false
-
SamWhited
oh, then that's not a quote or bold because you sent styling=false, so don't convert it into your NewMarkup
-
SamWhited
oooh, or are you suggesting that you want half the message to be styled, but part of it not to be? eg. that should be a quote in your markup, but not bolded foo?
-
pep.
I don't like the either all or nothing "feature"
-
SamWhited
ahh, gotcha, sorry, that's what I didn't understand about this entire conversation.
-
pep.
That's been my pitch for 2 years. Thanks for reading :(
-
SamWhited
pep. yes, I know, but from your previous message it seemed like you were making a completely different argument.
-
SamWhited
My mistake, I understand now.
-
theTedd
pep's point is that styling should really be an input method, not wire format; any formatting that's then applied becomes wire format using whatever-rich-markup; the fact we're dealing with this at all is because it's already used and some clients want to be clever and apply the styling automatically
-
pep.
theTedd, thanks :p
-
pep.
SamWhited, which is why I think the hint is not gonna help (not much at least, it's a small improvement)
-
SamWhited
I think they should apply it automatically, but if we add styling=false as a hint, clients could always add that if they wanted and only disable it if the user clicked the "bold" button or the "style this message" button explicitly
-
SamWhited
So that seems fine if that's something you want to do.
-
pep.
The hint is not sufficient
- sonny has left
- sonny has joined
-
pep.
https://lab.louiz.org/poezio/poezio/issues/3455#note_7769 Have you read this? Replace "XHTML-IM" but "some wire format" if you prefer✎ -
SamWhited
pep. I was responding to theTedd's thing, you're right that it's not sufficient to style only part of the message but it't not for that
-
pep.
https://lab.louiz.org/poezio/poezio/issues/3455#note_7769 Have you read this? Replace "XHTML-IM" by "some wire format" if you prefer ✏
-
theTedd
the second point is 'what' should they apply automatically? obviously you say 0393, but a client may support another -- the hint would indicate which
-
SamWhited
pep. yes, you can do that just fine with styling. You parse the message as its being typed, and if you get a "bold" or whatever you convert it to your XHTML, that seems fine.
-
pep.
SamWhited, you can't actually do that with styling
-
pep.
Because you're gonna send "*foo*" in both cases
-
SamWhited
If you hit backspace, remove your internal XHTML styling for that one element and don't update it anymore
-
SamWhited
(unless it changes)
-
pep.
Ah you're talking about a proper wire format. Sure
-
SamWhited
You are right that remote clients that support XHTML-IM vs. remote clients that support styling will show different things
-
SamWhited
But styling doesn't do fonts or sizes or whatever else XHTML-IM did anyways, it's not an exact replica, so this will be true no matter what.
-
pep.
I'd be happy just having what styling does with a proper wire format. That is, styling only used as input format
-
SamWhited
Yes but that would make things far more complicated, and unnecessarily so when it works fine most of the time.
-
SamWhited
And you can do what that issue wants today easily enough, so why add more complexity?
-
pep.
more complicated, surely. But that doesn't lock us up with this format and all its disadvantages
-
pep.
I can't do that already, since I can't parse what I receive properly
-
SamWhited
You're not locked up with this format as you say anyways, feel free to do your own thing.
-
theTedd
SamWhited, what's the complication? either apply styling (hint=true) or don't (hint=false), or do what you already did when hints didn't exist (no hint)
-
SamWhited
pep. why can't you parse it? Parse the whole message, convert it to XHTML-IM, remove any HTML around bits where the user hits backspace, and call it a day
-
pep.
SamWhited, same issue, I don't know in your message what is styling and what isn't
-
SamWhited
theTedd: I was talking about pep.'s suggestion that we add wire format around all the styled sections. hint=false is fine and doesn't add significant complexity.
-
SamWhited
pep. it's all styling unless they hit backspace right after entering the text.
-
theTedd
SamWhited, okay, but why is true a difficulty?
-
pep.
SamWhited, that's fine when sending but not when receiving
-
SamWhited
theTedd: true isn't difficult, it's just unnecessary and makes there be lots more states
-
SamWhited
pep. okay, we were talking about sending I thought. When receiving if you support XHTML use that, if not, the whole message is styling because that's the way styling works.
-
theTedd
SamWhited, there are three states: true, false, none -- none is what already exists
-
pep.
SamWhited, right, and that's why I say we're locked up with styling
-
SamWhited
pep. so don't support styling if you don't like it, I don't see what the problem is.
-
SamWhited
or just support it as an input method and then send XHTML-IM or whatever.
-
theTedd
pep., this is documenting what's already used, it's never going to turn into a real markup wire format and people are always going to do *this*
-
pep.
theTedd, by encouraging client devs not to do anything about it
-
pep.
"yeah it's fine, while you could help fix the state, just put stuff on the wire who cares"✎ -
pep.
"yeah it's fine, while you could help fix the current state, just put stuff on the wire who cares" ✏
-
theTedd
I agree, but devs are lazy and will take a library you throw at them when it exists
-
SamWhited
pep. you're assuming that everyone else thinks this is bad somehow too, but we're not trying to just stick everyone with the current thing to be jerks, we're documenting it because we believe that it's good enough as is and works well in practice.
-
pep.
SamWhited, I'm not saying this is not good for users
-
Ge0rG
You can't fix the current state, you only can fix a future that comes after you created a XEP and got it widely implemented
-
pep.
I'm saying users only care about the input format
-
pep.
I'm not sure what's wrong about this statement
-
pep.
And if we agree, can we move towards this please
-
SamWhited
I agree that users don't care what's happening behind the scenes, they just want to type *bold* and see their text be bolded.
-
pep.
yes
-
theTedd
ideally, we should, but right now people are doing (and will continue to do) do inline text formatting, so that does still need to be handled
-
SamWhited
Which is why the fact that their text is being sent behind the scenes and then parsed as-is is not something users care about and works fine.
-
pep.
SamWhited, but why encourage devs not to care about what goes on the wire
-
theTedd
'fine' -- it's hacky at best
-
SamWhited
pep. why should they care if it works fine?
-
pep.
I'm not sur ewhat's to gain here
-
SamWhited
Let's refocus this discussion:
-
pep.
it doesn't "work fine"
-
pep.
Just like theTedd said it's hacky at best
-
SamWhited
I *think* the fundamental disagreement here is that if I type "this is *bold* and this is *not bold*" you think the second one should have the option of not being bold, right? Or is there something else?
-
pep.
yes
-
pep.
this
-
SamWhited
okay, so let's ignore wire format, user input methods, etc. since those are just consequences of wanting this feature.
- Wojtek has joined
-
pep.
Well "this feature" also possibly being accidental
-
SamWhited
Instead, let's figure out exactly what features we want, then we can figure out if it's possible to do it with the current thing or if we need tons of wire format.
-
pep.
I type something and it gets interpreted wrongly
-
SamWhited
pep. I didn't undestand that, what did you mean by "being accidental"?
-
pep.
"> <" being just one example
-
SamWhited
So having a styling=false hint fixes that example.
-
pep.
Just got another example on another channel with gajim interpreting received ":/" as an emoji (when it was part of or URI: foo://bar). Not styling, but same kind of problem to me
-
SamWhited
Also, I suspect that it's rare enough in practice that we don't have to care.
-
pep.
SamWhited, it "fixes" that example if that's the only thing in the message
- sonny has left
-
theTedd
pep., you can't fix 0393 to do that - it's not going to happen
-
SamWhited
pep. and I'm saying that's not a huge problem if one message on rare occasions has to have no styling because you want to display something that would conflict.
-
pep.
theTedd, I know and that's why I don't want 393 :)
-
theTedd
SamWhited, you're defending 0393 when pep is really arguing for an alternative
-
SamWhited
theTedd: yes, I'm defending it saying that we don't need an alternative, or that if pep. wants one accepting 393 doesn't stop him from writing one.
-
pep.
The thing is that you're also forcing 393 on me (as a user, and client dev)
-
theTedd
pep's argument is that providing this reduces the motivation to do anything else because "it largely works"
-
pep.
And I'd like to prevent that
-
SamWhited
Again, I'm really not. You don't have to implement 393.
-
pep.
But I can't stop receiving maybe-393 payloads
- undefined has left
-
SamWhited
pep. you can't stop receiving those anyways, people are *already* typing asterisks and what not.
-
SamWhited
It doesn't matter if the spec exists or not.
-
theTedd
hint=true would at least make it explicit what you're receiving
- undefined has joined
-
pep.
SamWhited, and if their client supported something that had a proper wire format, I would know
-
pep.
And I could interpret them differently
-
pep.
So yes in a way you're forcing me to implement 393 to be able to parse it and convert it to something else. Even if it might not be a 393 payload
-
SamWhited
You can already do that. If you get your other wire format, interpret it as that. If not, interpret it as styling unless it has a hint=false.
-
SamWhited
Or don't implement styling at all and only support your other wire format if you get that.
- susmit88 has joined
-
pep.
I'm not sure where I'm not clear on this
-
pep.
Why don't you see you're actually forcing me to implement it
-
pep.
well, "you", clients implementing 393
-
pep.
You by extension
-
SamWhited
Lots of clients already implement 393, it's just not called that and they all have slightly different rules.
-
SamWhited
This spec doesn't change that.
-
pep.
Let's just talk about the spec
-
SamWhited
The spec doesn't change anything, so it's not forcing you to implement or not implement anything.
-
pep.
Ok I'm giving up sorry
-
pep.
It's being vetoed anyway so..
- paul has left
-
SamWhited
Possibly stupid question: does anyone know if there's a name for the emoji pep. mentioned? ("> <")? I'm just trying to figure out what it is so I can use it in an example maybe
-
SamWhited
I've never seen it before
-
theTedd
kaomoji
-
SamWhited
Thanks. I don't see that one in this list of kaomoji, but I'll keep looking
-
pep.
😖😫 < some variant of these
-
SamWhited
I see a few other faces that use ><, but they're all wrapped in quotes, or don't have a space after the ">" so they wouldn't be quotes anyways
-
SamWhited
wrapped in parens, I mean
-
theTedd
they tend be much more complex with various unicode characters
-
pep.
←(>▽<)ノ
-
SamWhited
pep. that wouldn't conflict or be a quote, so no problem with that one
-
pep.
SamWhited, not sure what you're trying to do here anyway
-
pep.
it's just one example
-
SamWhited
pep. I know, I want to use it in an example in the XEP of disabling the styling hint
-
SamWhited
So I was just trying to find what that emoji represented, but I can't find it anywhere
-
SamWhited
If the way it's actually written doesn't actually conflict, it's not a good example for me to use
-
theTedd
the 'real' way might not, but people lazily type >< because it's quicker
-
Zash
>_>
-
SamWhited
ah, gotcha. Okay, I'll just use it in the example then as is and say that it's an emoji without naming it. Thanks.
-
pep.
Also a quote from Zash in dino@ the other day: "That's how it works on *nix afaik, $LANG and $LC_* etc"
-
Zash
😒️
-
pep.
And I can grep through logs if you want a lot more
-
SamWhited
pep. that's okay, I just needed one and the emoji example is a good one to use since people will probably understand it
-
SamWhited
thanks
- paul has joined
- sonny has joined
- sonny has left
- susmit88 has left
- sonny has joined
- susmit88 has joined
- theTedd has left
- susmit88 has left
- susmit88 has joined
- sonny has left
- sonny has joined
-
pep.
hmm so what's the status of the 157 PR? "Accepted but"?
-
jonas’
pep., accepted, but flow wants to investigate whether he wants to improve it before we get it into Active
- larma has left
-
jonas’
(in which case we’ll have to re-vote)
-
jonas’
oh, also, Ge0rGs vote is pending
-
jonas’
so it’s *not* accepted at this stage
-
jonas’
but even if Ge0rG had already not-vetoed it, The Editors™ would delay the merge until flow reports back
-
pep.
should I change it to WIP or sth? (after Ge0rg votes?)
-
pep.
or blocked or..
-
Ge0rG
Should I just delay my vote?
- larma has joined
- David has joined
- bear has left
-
jonas’
pep., there is a "Draft" button
-
jonas’
that would probably be appropriate
-
jonas’
also, for the record, we voted on d902893✎ -
jonas’
also, for the record, we voted on d902893 ✏
-
jonas’
having it written down here makes it easier to keep track when re-reviewing the thing
-
pep.
jonas’: yeah that's what I meant
-
Zash
what's that, a case where using github doesn't make things better? :)
- sonny has left
- sonny has joined
- Wojtek has left
- sonny has left
- sonny has joined
- Wojtek has joined
- debacle has left
- bear has joined
- sonny has left
- kusoneko has left
- kusoneko has joined
- kusoneko has left
- kusoneko has joined
- kusoneko has left
- kusoneko has joined
- kusoneko has left
- kusoneko has joined
- vaulor has left
- SouL has left
- vaulor has joined
- SouL has joined
- susmit88 has left
- debacle has joined
- susmit88 has joined
- debacle has left
- debacle has joined
- sonny has joined
- kusoneko has left
- kusoneko has joined
- sonny has left
- sonny has joined
- sonny has left
- kusoneko has left
- kusoneko has joined
- sonny has joined
- stpeter has left
- sonny has left
- sonny has joined
- eta has left
- sonny has left
- eta has joined
- sonny has joined
- stpeter has joined
- sonny has left
- sonny has joined
- susmit88 has left
- susmit88 has joined
- robertooo has left
- susmit88 has left
- susmit88 has joined
- sonny has left
- Tobias has left
- susmit88 has left
- susmit88 has joined
- daniel has left
- daniel has joined
- undefined has left
- susmit88 has left
- susmit88 has joined
- robertooo has joined
- susmit88 has left
- susmit88 has joined
- susmit88 has left
- susmit88 has joined
- stpeter has left
- debacle has left
- stpeter has joined
- paul has left
- susmit88 has joined
- debacle has left
- Wojtek has left
- daniel has left
- daniel has joined
- kusoneko has left
- kusoneko has joined
- stpeter has left
- susmit88 has left
- susmit88 has joined
- stpeter has joined
- susmit88 has left
- susmit88 has joined
- stpeter has left
- stpeter has joined
- Tobias has joined
- susmit88 has left
- susmit88 has joined
- stpeter has left
- stpeter has joined
- stpeter has left
- paul has joined
- stpeter has joined
- stpeter has left
- kusoneko has left
- kusoneko has joined
- stpeter has joined
- stpeter has left
- 3ch0 has joined
- bear has left
- 3ch0 has left
- stpeter has joined
- stpeter has left
- stpeter has joined
- bear has joined
- Tobias has left
- Tobias has joined
- stpeter has left
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- stpeter has joined
- stpeter has left
- larma has left
- stpeter has joined
- larma has joined
- debacle has joined
- stpeter has left
- larma has left
- larma has joined
- stpeter has joined
- stpeter has left
- stpeter has joined
- stpeter has left
- stpeter has joined
- eta has left
- eta has joined
- stpeter has left
- stpeter has joined
- stpeter has left
- stpeter has joined
- hotspud has left
- hotspud has joined
- vaulor has left
- SouL has left
- vaulor has joined
- SouL has joined
- stpeter has left
- Zash has left
- Zash has joined
- stpeter has joined
- stpeter has left
- stpeter has joined
- undefined has left
- stpeter has left
- undefined has joined
- stpeter has joined
- stpeter has left
- eta has left
- eta has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- stpeter has joined
- moparisthebest has left
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- daniel has left
- daniel has joined
- eta has left
- eta has joined
- daniel has left
- daniel has joined
- dwd has joined
- undefined has left
- undefined has joined
- undefined has left
- undefined has joined
- moparisthebest has joined
- undefined has left
- undefined has joined
- undefined has left
- undefined has joined
- sonny has left
- sonny has joined
- undefined has left
- undefined has joined
- susmit88 has left
- sonny has left
- sonny has joined
- sonny has left
- sonny has joined
- sonny has left
- sonny has joined
- sonny has left
- sonny has joined
- undefined has left
- undefined has joined
- sonny has left
- sonny has joined
- theTedd has joined
- sonny has left
- sonny has joined
- Wojtek has joined
- sonny has left
- undefined has left
- undefined has joined
- susmit88 has joined
- paul has left
- paul has joined
- sonny has joined
- sonny has left
- susmit88 has left
- sonny has joined
- susmit88 has joined
- theTedd has left
- susmit88 has left
- susmit88 has joined
- sonny has left
- sonny has joined
- larma has left
- larma has joined
- David has joined
- bear has left
- sonny has left
- sonny has joined
- Wojtek has left
- sonny has left
- sonny has joined
- Wojtek has joined
- debacle has left
- bear has joined
- sonny has left
- kusoneko has left
- kusoneko has joined
- kusoneko has left
- kusoneko has joined
- kusoneko has left
- kusoneko has joined
- kusoneko has left
- kusoneko has joined
- vaulor has left
- SouL has left
- vaulor has joined
- SouL has joined
- susmit88 has left
- debacle has joined
- susmit88 has joined
- debacle has left
- debacle has joined
- sonny has joined
- kusoneko has left
- kusoneko has joined
- sonny has left
- sonny has joined
- sonny has left
- kusoneko has left
- kusoneko has joined
- sonny has joined
- stpeter has left
- sonny has left
- sonny has joined
- eta has left
- sonny has left
- eta has joined
- sonny has joined
- stpeter has joined
- sonny has left
- sonny has joined
- susmit88 has left
- susmit88 has joined
- robertooo has left
- susmit88 has left
- susmit88 has joined
- sonny has left
- Tobias has left
- susmit88 has left
- susmit88 has joined
- daniel has left
- daniel has joined
- undefined has left
- susmit88 has left
- susmit88 has joined
- robertooo has joined
- susmit88 has left
- susmit88 has joined
- susmit88 has left
- susmit88 has joined
- stpeter has left
- debacle has left
- stpeter has joined