Arcno its pretty much what we already have. as long as the characters are shown i think its good. KISS.
Arcescape characters make it overly complex
Ge0rGhas left
moparisthebestI always want to say something is KISS but I wasn't sure if it translated or might insult someone :)
ArcKeep It Simple Stupid
Steve Killehas left
Arcthats a very old one.
SouLhas left
SamWhited*nods* sounds good to me.
lumihas left
@Alacerhas joined
Ge0rGhas left
Arci was putting together a media attachements xep last winter
Arci think we even added support for it
Archttps://pastebin.ca/3905635
Arcwhat we didnt resolve is ensuring that <thumb> accurately reflected the media being shared.
ArcURLs are difficult regardless. you certainly cant have clients autoloading them because they can unmask anonymity
Ge0rGhas left
Syndacehas joined
Valerianhas left
Valerianhas joined
bjchas left
Ge0rGhas left
vanitasvitaehas left
Guushas left
Ge0rGhas left
Valerianhas left
danielhas left
danielhas joined
Guushas left
Ge0rGhas left
Ge0rGhas left
pep.SamWhited, I honestly wonder if you are ignoring all feedback from the previous XHTML-IM thread. but then it's time to sleep, I'll try to post on the list tomorrow
danielhas left
danielhas joined
SamWhitedI was wondering if everyone was ignoring my responses to all feedback from the previous thread.
pep.:)
SamWhitedBut maybe we shouldn't get into that, because that's going to be an unproductive discussion. Please explain what you think was ignored instead of making inflamatory statements.
pep.Sure, I'll post on the list, going to bed now
danielhas left
danielhas joined
Tobiashas joined
Ge0rGhas left
danielhas left
Ge0rGhas left
danielhas joined
la|r|mahas joined
Steve Killehas left
danielhas left
Tobiashas joined
danielhas joined
Ge0rGhas left
danielhas left
danielhas joined
ArcI'm really not interested in arguments that xhtml-im can be hypothetically implemented in a secure manner. its been in use for a long, long time and I'm not aware of a single secure implementation of it.
Arcthe thin benefits it provides to users cannot possible outweigh the risks
Ge0rGhas left
Ge0rGhas left
Steve Killehas left
Ge0rGhas left
sonnyhas left
sonnyhas joined
bjchas left
bjchas joined
danielhas left
danielhas joined
Steve Killehas left
Ge0rGhas left
moparisthebestXhtml-im's main benefit is it's easy
moparisthebestThat's also it's main downfall, easy to shoot yourself in the foot
Ge0rGhas left
Guushas left
Ge0rGhas left
la|r|mahas joined
Syndacehas joined
Syndacehas joined
lskdjfhas joined
Ge0rGhas left
danielhas left
jerehas joined
danielhas joined
Ge0rGhas left
danielhas left
danielhas joined
Ge0rGhas left
Arcwe had a presentation at ctrlh two weeks ago on "sanitized" html
Steve Killehas left
Arcdifferent browsers parse slightly different, and in those differences, you can sneak script through
Arcin one of the examples he used a utf8 quote inside <img width=> to get the sanitizer to believe it was all part of the value, but then include a ton of extra stuff
SamWhitedthat's a good one I haven't seen before
Steve Killehas left
Arcit was one of the trickier ones, and they all were limited to certain browsers
danielhas left
danielhas joined
Arcthe other presentation was on a USB charging cable a guy had made with a GSM modem and SIM card slot hidden in it, and it would start uploading data from the users phone when they plugged it in
Ge0rGhas left
ZashArc: Would that still work after some round trips through an XML parser?
Arcidk, i guess it depends on the exploit
Arcsome of them had quotes within quoted values
Arcat least one of them relied on the sanitizer modifying the value to remove escapes
Steve Killehas left
Arcanyway they were all web-based examples and the main takeaway was if you need to allow html, put it in an iframe loaded from outside your trusted domain. such as every message from the same user from <user>.usermsg.mydomain so if they do manage to run javascript, it won't be able to access anything else
Arcthats actually not a solution i had considered in dealing with the candy problem
Arcive been trying to find the video of the presentation but i dont think its been uploaded yet
nycohas left
nycohas joined
Ge0rGhas left
uchas joined
danielhas left
danielhas joined
Ge0rGhas left
SamWhitedhas left
danielhas left
danielhas joined
Guushas left
bjchas left
Zashhas left
Zashhas left
Ge0rGhas left
Zashhas joined
@Alacerhas left
Ge0rGhas left
Guushas left
@Alacerhas joined
Ge0rGhas left
Ge0rGhas left
bjchas left
bjchas joined
waqashas joined
moparisthebestArc: plain old CSP header doesn't protect you?
danielhas left
danielhas joined
Ge0rGhas left
tuxhas joined
Ge0rGhas left
moparisthebesthas joined
Tobiashas joined
Ge0rGhas left
Guushas left
@Alacerhas left
waqashas left
@Alacerhas joined
Ge0rGhas left
jcbrandhas joined
Ge0rGhas left
jcbrandhas left
Arcafaik that only works with an iframe
Arcwhich means every msg must be in an iframe
Archas left
Archas joined
intosihas joined
jcbrandhas joined
jcbrandhas left
Steve Killehas left
danielhas left
danielhas joined
Ge0rGhas left
Guushas left
archas left
archas joined
Archas left
Guushas left
tuxhas joined
tuxhas joined
archas left
archas joined
Guushas left
Ge0rGhas left
danielhas left
danielhas joined
Guushas left
Guushas left
Steve Killehas left
Ge0rGhas left
Steve Killehas left
danielhas left
danielhas joined
jonaswCSP could work, I think, if you say that no inline script whatsoever is allowed and all scripts you need for operation come via script tags
jonasw(and then some strict policy where those scripts can come from etc.)
archas left
archas joined
archas left
archas joined
Ge0rGhas left
Steve Killehas left
Steve Killehas left
danielhas left
danielhas joined
Guushas left
Steve Killehas left
Steve Killehas left
danielhas left
danielhas joined
Ge0rGhas joined
Ge0rGhas joined
Ge0rGhas left
Ge0rGhas left
Ge0rGhas joined
Ge0rGhas joined
Zashhas left
Ge0rGhas left
Ge0rGhas joined
Archas joined
Ge0rGhas left
Steve Killehas left
Ge0rGhas left
jcbrandhas joined
nycohas left
danielhas left
danielhas joined
nycohas joined
mimi89999has left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
Ge0rGhas left
danielhas left
danielhas joined
Ge0rGhas joined
danielhas left
danielhas joined
Steve Killehas left
intosihas left
danielhas left
danielhas joined
danielhas left
danielhas joined
goffihas joined
Steve Killehas left
Steve Killehas joined
danielhas left
danielhas joined
danielhas left
danielhas joined
Steve Killehas left
intosihas joined
vanitasvitaehas left
archas left
archas joined
Archas left
vanitasvitaehas joined
Ge0rGhas left
ralphmhas left
@Alacerhas left
danielhas left
@Alacerhas joined
Martinhas joined
danielhas left
danielhas left
danielhas left
danielhas left
danielhas left
danielhas left
ralphmhas left
Zashhas left
Martinhas left
Martinhas joined
jonaswhas left
Martinhas left
zinidhas left
marchas joined
la|r|mahas joined
danielhas left
Ge0rGhas joined
danielhas left
lskdjfhas joined
Alexhas joined
danielhas left
intosihas left
la|r|mahas left
la|r|mahas left
la|r|mahas joined
la|r|mahas left
la|r|mahas left
la|r|mahas left
Ge0rGhas left
la|r|mahas left
SyndaceAbout the proposed styling XEP: What do you need service discovery for? I thought a key point of this spec was, that it doesn't matter whether the receiver supports this XEP or not.
vanitasvitaehas left
Ge0rGhas left
la|r|mahas left
Ge0rGhas left
jerehas joined
danielSyndace, yes I agree. I was meaning to propose getting rid of that. but it doesn't really hurt either so and there were more important things to talk about
danielhas left
danielhas left
sonnyhas left
sonnyhas joined
Kevhas joined
Zashhas left
Tobiashas left
lumihas joined
Kevhas left
danielhas left
danielhas left
tuxhas left
Alexhas left
Guushas left
Alexhas joined
Zashhas left
danielhas left
mimi89999has joined
jerehas left
jerehas joined
la|r|mahas left
Guushas left
jabberatdemohas joined
Alexhas left
Alexhas joined
Alexhas left
Alexhas joined
Guushas left
FlowSyndace, even if disco is not required by the protocol, it's still nice that you can use it to get an idea how widespread it is implemented
SyndaceFlow, but it's a MUST
Valerianhas joined
FlowSyndace, and that is problematic because? (Although I can see that a SHOULD may be ok too)
jabberatdemohas left
SyndaceI just personally don't see how the discovery should be used. My $client won't behave any different if it detects support or not. It won't strip out asterisks just because the reveicing person does not advertise support.
SyndaceIMO it's always a good idea to keep specifications as thin as possible, only including things that are needed for it to work.
SyndaceAnd disco is definitely not required for it to work
SyndaceI mean, all clients available probably support XEP-0030 so its no additional work in that specific case but still, why require something you don't need.
Guushas left
SyndaceThough I'm fine with looking at more important things first, as danial said
jerehas joined
jubalhhas joined
jubalhhas left
Alexhas left
FlowSyndace, as I said, it allows you to get an impression how widespread the xep is implemented
FlowYou may argue that it's more overhead for little benefit, but I think I would disagree with that
moparisthebestif it's just for "an impression for how widespread it's implemented" then it should go away
moparisthebestthat's what looking at code is for, it's not like there are so many clients you can't tell
GuusDiscussions like these are why we can't have nice things, guys. Lets fine-tune later.
zinidGuus: for example? :)
Guuszinid: we (myself included) are bikeshedding to much, in my opinion. That causes us to not be very productive, which in turn fuels the argument that XMPP is outdated / obsolete.
GuusI feel that we need to build momentum.
Syndacehas left
moparisthebestrushing crappy specs to production is a problem at the other end of the spectrum though
zinidisn't all this xhtml/mardown rantings a bikeshedding? :)
dwdmoparisthebest, I'd love our problem to be that we design and implement things too quickly.
dwdzinid, Much of it, yes.
zinidlike this is the most serious problem in xmpp?
zinidwhere are the priorities?
zinidwe don't have avatars working goddamit
Guusmoparisthebest: now that I have you: could you enlighten me on a SSHL confusion that I have
Guusdid the config file syntax change between 17 and 18, or am I missing a file?
moparisthebestit didn't change, but the sni/alpn stuff was added in 18
moparisthebestand you used to be able to get away without a config file and specify everything as command line args, but with alpn/sni you need the config file
Guusaaah! Then that's likely it.
moparisthebestI need to write up the page on the wiki again, I just lost everything and haven't got around to it
GuusI think I got confused by the duplicate file name of /etc/default/sslh.conf and a missing file that likely should go in /etc/sslh ?
lskdjfhas joined
lskdjfhas joined
moparisthebestnormally it's /etc/default/sslh (which is a shell script) and /etc/sslh.conf or /etc/sslh/sslh.conf which is the config file
moparisthebestnot sure how debian packages it these days though
FlowGuus, I don't think that this is the reason we are not productive
moparisthebestGuus, until I get around to it there is a bit of an explanation here: https://wiki.debian.org/InstallingProsody#XMPP_over_HTTPS
moparisthebesteven though the section title is totally wrong, just ignore that :)
GuusThanks
GuusFlow: every bit helps.
FlowThe reason is that we try to reach consensus on an to early stage. It should be normal to have multiple (partly) competiting experimental XEPs
FlowIt would probably help to get the MUC-NG thing that is currently restricted to just what MIXs experiments with
Alexhas left
dwdWe should write a new file transfer protocol, too. Been a while since we did one of those.
intosihas joined
moparisthebestalso how about SRV records for connecting over QUIC
KevBittorrent is hot, I hear.
dwdKev, Not obscure enough for us. Maybe IPFS over XMPP?
Valerianhas left
Ge0rGCan't we just add our chat messages to the blockchain and call it a day?
Kevdwd: I'm referring to a particular summit discussion. 2007, maybe.
GuusKev: pics or it didn't happen.
KevIt's a discussion that would have been better to not have happened.
KevSo I'm ok with that.
Guus:)
dwdKev, Ah... I think that might be the summit before I started doing anything serious.
Kevhas left
Alexhas left
GuusYou've been serious for 10 years now? auch!
danielhas left
dwdGuus, Well, serious with XMPP is around 2004, actually. But I don't think I turned up to Summits straight away. Serious with Open Standards more generally goes back to 1997 or so.
danielmathieui: the people I talked to thus far aren't really interested in an actual assembly. (=having a physical space). I just submitted my xmpp talk to the fsfe assembly
mathieuiwell, saying "let’s meet up at time X" should be good enough
Valerianhas joined
Alexhas joined
bjchas left
Guusoh, that's to bad. There's plenty of you going
bjchas joined
Alexhas left
bjchas left
Alexhas joined
bjchas joined
danielhas left
danielhas left
Ge0rGWhat is the accepted behavior for candidates in the vote on themselves? abstain once and vote 4 others? Vote 5 others? Not vote at all?
danielJust vote for yourself. Who cares
MattJAs far as I understand, you're allowed to vote for yourself, so if you think you should be in, vote
danielExcept if you believe you aren't suited for the job of course
Ge0rGisn't that pretty awkward to candidate for a position you think you are not well-suited for?
danielThat's the trump way
Ge0rGthat's a candidacy everyone else thinks you are not well-suited for.
Ge0rGOkay, might be me for Council as well
efrithas joined
dwdGe0rG, We have had people stand before specifically to make an election contested.
Ge0rGdwd: wow. That's pretty crazy
dwdGe0rG, Presumably they felt they could do the job if selected, but I could see they might vote against themselves.
dwdOr might have voted. It was some time ago.
danielhas left
danielhas left
Kevhas left
intosihas left
intosihas joined
moparisthebesthas joined
Zashhas left
danielhas left
la|r|mahas left
la|r|mahas joined
intosihas left
intosihas joined
efrithas left
lumihas left
uchas left
mathieuiif I understand correctly I have a flamewar to catchup
moparisthebestI tried to revive this page if anyone is interested https://wiki.xmpp.org/web/Tech_pages/XEP-0368
sonnyhas left
sonnyhas joined
Syndacehas joined
nycohas left
nycohas joined
jcbrandhas left
zinidhas left
Kevhas left
jubalhhas left
tuxhas joined
Guushas left
ralphmhas left
zinidhas left
jubalhhas left
waqashas left
danielhas left
Valerianhas left
nycofound this paper, has it been discussed already? https://eprint.iacr.org/2017/666.pdf
Tobiashas joined
waqashas joined
waqashas left
jubalhhas joined
Guushas left
jjrhhas left
SamWhitedRE Styling, the thing I haven't gotten feedback on so far is the type of styling itself. Does this encompase peoples needs as far as IM goes? (I know some people want a full formatting and layout engine, but that's out of scope)
SamWhitedOr is it too much even? Eg. is there any point in having ~strikeout~ which I doubt anyone will ever use?
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
jjrhhas left
jjrhhas left
sonnyhas left
sonnyhas joined
jjrhhas left
jjrhhas left
Syndacehas left
sonnyhas left
sonnyhas joined
GuusSamWhited: I
Guusoops
GuusI must admit I've not read it in detail, but as far as I'm concerned, a basic set (bold, underline, italic, with perhaps a couple of others) is more than enough for a boatload of usecases, therefor making it a practical XEP
GuusThere's likely other use-cases, but there's no need for one XEP to rule them all, right?
Steve Killehas left
Steve Killehas left
Steve Killehas joined
jonaswSamWhited, under the assumption that proper layouting is not possible, I think the things you include there are sufficient.
Steve Killehas left
jjrhhas left
jjrhhas left
Valerianhas joined
Guushas left
Steve Killehas left
Steve Killehas left
intosihas left
archas left
Steve Killehas left
Steve Killehas left
archas joined
Kevhas left
SamWhitedGuus: is underline a requirement for you? Having that makes more sense to me than strikeout, but I don't have it right now
archas left
valohas joined
archas joined
jonaswI don’t think that underline is a good idea in general.
SamWhitedyah, I'm not sure how useful that one is either; just slightly more useful than centerline
SamWhited(maybe)
jonaswI’d say the opposite.
jonaswwe already have two ways to emphasise things in that protoxep
SamWhitedThat's fair too, semantically they're probably the same
SamWhitedNow I'm even less sure :)
archas left
archas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas joined
sonnyhas joined
sonnyhas joined
sonnyhas joined
sonnyhas joined
sonnyhas joined
valohas joined
archas left
archas joined
lumihas joined
archas left
lovetoxhas left
lovetoxhas joined
moparisthebestI think _underline_ is supported in gajim though
moparisthebestyep, that underlined it
jonaswthat some client supports it doesn’t make it a good thing
moparisthebestwhy not, specify what's already implemented most places, make them all optional, done
Zashyou keep repeating "most places/clients"
jonasw> We are not typing on typewriters any more. We are using computers. Word processors, HTML, CSS. Underlining means a hyperlink. Period. If you want to emphasize something, use bold, italics, indents, all caps, or any combination thereof.
GuusSamWhited: underline is not a requirement for me, but it's somewhat of a default featureset, right?
Guusbut, to be honest, I don't care to much. My point was: keeping it simple is good.
jonaswI don’t think you can do that anymore in e.g. Markown or rST
SamWhitedGuus: I'm not sure; Slack and Whatsapp don't support it.
SamWhitedAnd I think they count as "most things" more than Gajim does.
SamWhitedI'll leave it off for now for the sake of simplicity; we can add something later if it's a problem.
edhelashas joined
SamWhitedMight take strikeout out too
Steve Killehas left
archas joined
moparisthebestSamWhited, what about disco
GuusSamWhited: as I said: I'm not bothered by the exact set. I'm just gratefull you're keeping it short/simplish.
archas left
archas joined
archas left
archas joined
SamWhitedmoparisthebest: oh yah, I saw that discussion. I'm fine with removing it.
SamWhitedDoesn't matter to me either way
SamWhitedI was going to wait to see if it was accepted or not before pushing more changes
Guushas left
archas left
archas joined
archas left
archas joined
archas left
archas joined
tuxhas left
archas left
archas joined
archas left
archas joined
ralphmhas joined
daniel> Might take strikeout out too
I think the ~ character is rare enough that it won't cause trouble and slack and whatsapp are doing it. So in the interest of making transports work I'd just leave it in.
danielhas left
ZashLet me tell you about my ~/stuff
moparisthebestthat's fine you didn't put it twice
moparisthebestwait is ~/stuff/~ a valid path?
danielZash: that's lacking the closing keyword though
moparisthebestI don't think I want to know...
jonaswmoparisthebest, it is
Flowwhy shouldn't it be a valid path?
Valerianhas left
moparisthebestdangerous to delete :)
Guushas left
intosihas joined
Flowjonasw, just upvoted https://writers.stackexchange.com/a/4680, nobody needs underline if you don't write on a board or on a paper
jonaswGuus, could you cancel the second-newest build please? https://hub.docker.com/r/xmppxsf/xeps/builds/
jonaswI may be stupid, but (re styling):
> Matches MUST NOT extend over newlines and MUST start with a whitespace character or be the beginning of the line or the byte stream.
how does that match with the example "*emphasized*foo*emphasized*" where "foo" is not emphasized?
danielhas left
danielhas left
Guuscancelled
archas left
jonaswGuus, thanks -- even though I don’t see it in the UI yet.
SamWhitedgood eye, that's broken
SamWhitedI have those rules tweaked a bit based on feedback locally anyways
danielhas left
jonaswSamWhited, re standards@:
> A 100% solution with no false positives would be great, but I
> can't think of a way to do it without significantly more complexity or a
> formal markup language (which is against the requirements I drew up
> based on previous discussions).
what’s wrong with a formal markup language if we’re gonna need a parser which can handle context-free grammars anyways?
danielI'd love to know what matrix is doing and eventually try to convince them to use the same syntax (to make transports) but matrix is impossible to Google
Guus(now I _really_ cancelled it)
SamWhitedjonasw: duplicate content, even more complexity, etc.
archas joined
jonaswIIRC from my compiler construction lectures you need an LR parser for a CFG which is already quite a complex beast.
SamWhitedIt's really not
SamWhitedI don't think you need an LR parser here though
jonaswwould have to take a deeper look. In any case, writing down the grammar formally is probably a good idea
SamWhitedI think we're over thinking this. I've got an implementation which I'll push somewhere soon and it's relatively straight forward.
SamWhitedI'm not even bothering to build an AST (though doing that would make things much faster)
jonaswGuus, yay :-)
ZashWhat's that, just s/\*.*\*/<b>&</b>/ and stick it in innerHTML?
ZashGood idea
jonaswZash, you forgot the \b before the \*, they must be on word boundaries (essentially)
SamWhitedActually, if I remove escaping and strike out it may be possible to make a few minor tweaks and make this regular
SamWhitedThat would simplify things a lot
Kevhas joined
jonaswhm, doesn’t the precedence of block over monospace over other inline already make this non-regular?
SamWhitedah yah, you're right, having block level things probably still make that impossible
Valerianhas joined
goffihas left
Alexhas left
Ge0rGJust for reference. The last time I tried to escape on slack, I have given up after three futile correction attempts.
SamWhitedThat's probably a good reason to remove the escape chars
Ge0rGMaybe there are no escape chars on slack, and this is why I failed. We'll never know.
SamWhitedI did look at their docs and I don't remember any mention of a way to escape formatting chars
GuusAt this point, let's publish something and start experimenting with implementations
Ge0rGYeah. You can't escape slack
SamWhitedGuus: There are at least two implementations already :) (Daniel and I both have one)
SamWhitedI don't think it's complete either. I also have one in library form that I will push somewhere "soon"
Alexhas joined
GuusCool. Let's start gaining experience with this, and discuss it from there.
danielGuus, SamWhited: the current beta has this.
Ge0rGI'm sure it will freak out admins, developers and mathematicians
Guuslet's see if I can hack this in Spark real quick
archas left
archas joined
intosihas left
Guushas left
Guustest _foo_ *bar* ~foobar~
Guuswhy's ~this~ bold and strikethrough?
Guusah, doesn't reset
Valerianhas left
Guushas left
Guushas left
Guusokay. Split by whitespace, checking first and last character only - Not what's in the xep, but it'll give me some feelign on how this looks
Guusso far, I'm not unhappy.
KevI've not looked at the protoXEP yet, been busy. Is it basically *bold* /italics/ _underline_ ?
lskdjfhas left
SamWhited*bold*, _italics_, and ~strikethrough~
SamWhited(although I was thinking of removing ~strikethrough~)
KevCan we have /italics/ and _underline_ please? :)
KevIf we do that, I have an implementation that predates the protoXEP by about 15 years.
SamWhited/italics/ seems nice but also likely to conflict with paths and URLs, Slack and Whatsapp both do _italics_ so I felt it was best to immitate what they were doing, but I coudl be convinced otherwise
KevSlack and Whatsapp both annoy me for getting this wrong :)
SamWhitedI'd rather follow convention unless there's a compelling reason not to
SamWhited(but I do agree that I think those make more sense)
KevSee above - I've got about 15 years of convention for you :D
Guushas left
KevBut it depends what you want.
Tobiasbut silicon valley knows better
KevIf what you want is an input format, it doesn't matter much.
KevIf what you want is something that falls back to plain text gracefully, then /italic/ and _underline_ are better.
dwdKev, Gajim also does *bold* /italics/ and _underline_, but no ~strikethrough~.
Guus/italics/ is sooo 1997
GuusI've not seen that since.
dwdGuus, Yes, and your point?
Guuswho said I had a point?
SamWhitedI'm not sure that they are better though, regardless of how nice they look people are used to Slack and Whatsapp I think. Then again, I'm not sure it really matters all that much either way.
KevSamWhited: Except Slack never renders this.
Guushas left
KevIf you send *something* in Slack, you only ever see the bold, not the surrounding *
KevSo people aren't used to seeing _somethingitalic_
SamWhitedOh yah, it's a tiny bit different, but as far as the characters that people type goes they're used to writing _italic_
Guus(I like how this is rendering for me now :P )
SamWhitedI assume… I haven't used Slack except very briefly, I just read their docs.
ZashYou beat
KevI'm used to writing /this/ in Slack and wondering why they don't support italics.
ZashYou mean <i>hello</i>path/ is what you see in places
KevThis is not a hill for me to die on, but if we've got a 15 year old convention in existing clients, it seems weird to break that.
SamWhitedyah, I would say this is entirely bike sheddy, except that I do think the /path/to/foo is potentially an actual problem
SamWhitedWhat clients do this convention?
SamWhitedGajim? Any others?
dwdKev, I have to admit that although /italics/ is far more natural to me, I never use it (or _underline_ either).
KevI put it in Psi about 15 years ago.
moparisthebestit's not a problem if you leave all the characters always though SamWhited
SamWhitedThat's also fair
jubalhhas joined
SamWhitedI'm not saying that this should necessarily be a trendy popularity contest, but I suspect more people use Whatsapp and Slack than Psi and Gajim, so if it's just a matter of "people are used to this, it's a convention" then I'd still want to stick with what's in the protoxep now.
jonaswpeople are used to the input convention, not to the wire format (they don’t care about it, but we should)
jonaswfinally the build finished: https://xmpp.org/extensions/inbox/markup.html
SamWhitedjonasw: what is the number in span start/end?
jonaswit’s explained.
jonasw(codepoint in XML character data)
dwdjonasw, Read that already when I noticed the github notification. I'm undecided on that approach. I do think some of the failure cases with overlapping spans and blocks and so on are going to be weird.
SamWhitedah sorry, I was just looking for that earlier and didn't see it
SamWhitedWhat happens if I put it in the middle of a grapheme cluster composed of multiple code points?
jonaswSamWhited, it gets split when rendering.
jonaswI presume
dwdSamWhited, We've used a similar approach in <references/>, BTW.
SamWhited*nods*
jonaswdepends on your rendering engine I think
SamWhitedI wondered about it in references too actually
jonaswI was already wondering whether that is something which can be used as an exploit, but aside from splitting emojis and possibly cutting of accents from letters I don’t see how this could be abused
jonaswbut then again, unicode is weird.
vanitasvitaejonasw: looks nice
Guusgood job on formulating an alternative, jonasw
vanitasvitaejonasw: the introduction seems weird. I'm missing a "this approach thrives to solve the mentioned issues in the following way: ..."
Guuson first glance, I'm inclined to prefer the less complex version, but I love to see a documented alternative
jonaswvanitasvitae, I always forget that :)
danielhas left
SamWhitedminor nit: if you're sending an encrypted body this leaks information about the body. Probably not in any significant way, but it seems worth mentioning in the security considerations or somewhere.
jonaswGuus, I like the simplicity of the *input format* Sam suggests. I don’t like having it as the wire foramt.
Valerianhas joined
Guusjonasw, understood
goffihas joined
Guus(also, should that have been bold?)
jonaswno, my client can only into XHTML-IM and I’m too lazy to do that
Ge0rGSamWhited: I think the biggest design failure of omemo is to only encrypt the body...
daniel> minor nit: if you're sending an encrypted body this leaks information about the body. Probably not in any significant way, but it seems worth mentioning in the security considerations or somewhere.
This is a problem with all the references and annotations XEPs
jonaswSamWhited, good point. Admittedly, I was in a bit of a hurry because I only thought of this last night and I felt it’d be good to have the idea out before next council meeting.
danielBut as Ge0rG said this is rather a problem with omemo than with those xeps
Kevdaniel: I think the reverse is actually true.
KevThis is a problem with any encryption scheme that only encrypts the body.
KevAh, which you then said :)
jonaswisn’t that what daniel said?
SamWhitedAs I've previously expressed, I think it only makes sense for OMEMO (or anything really) to encrypt text nodes, not actual XML (now you've got a weird mixed-mode stream and that's going to lead to worse security issues later)
jonaswright
Ge0rGWe need to encrypt the meta data finally. That's what the services are after!
KevMy hotel wifi here is *not* fast.
SamWhitedSo even if it encrypted more than the body, I don't think it could encrypt this.
archas left
archas joined
SamWhitedBut that's a discussion for another time.
GuusI'm off. goodnight everyone.
KevNight.
SamWhitedo/
jonaswnighty Guus
daniel> As I've previously expressed, I think it only makes sense for OMEMO (or anything really) to encrypt text nodes, not actual XML (now you've got a weird mixed-mode stream and that's going to lead to worse security issues later)
It's a quite complicated problem. That's probably why nobody has solved it yet
Ge0rGMixing data and meta data is known to fail security since Captain Crunch. We should have learned from that by now.
goffijonasw: fantastic proposal, I really love it, thanks a lot for that !
Archas joined
jonaswgoffi, you’re welcome
SamWhitedjonasw: we've already discussed this a little bit I think, but what do you see as the benefits of doing it this way?
moparisthebestit would be quite neat to do hop-based encryption, like encrypt entire thing so your server knows to send it to otherserver.net but not who@otherserver.net, and that server can see who to send it to but not who it came from or whatever
jonaswSamWhited, I’m going to head to bed in a few minutes, so I don’t think we can discuss this at length now.
moparisthebestthat's getting more onion-routing-y though and is starting to sound like a protocol not-xmpp
SamWhitedsounds good
Ge0rGmoparisthebest: that fails for presence
Ge0rGmoparisthebest: there are protocols not xmpp that do it, like tox
moparisthebestwell tox is p2p without any hops right?
moparisthebestno servers anyway, I think
jonaswSamWhited, it provides the protocol break we need to make rich text safer (compared to XHTML-IM) and provides the formality which is needed to make it future-proofer (compared to ad-hoc text formats).
Zashmoparisthebest: p2p in the real world has servers, only they call them super nodes or something
jonaswSamWhited, I think that we shouldn’t be mixing input conventions with wire-level markup.
SamWhitedjonasw: why not?
jonaswthis is somewhere between a matter of design principle and concern about interoperability.
jonaswbecause input conventions only matter for humans, and may differ between different user interfaces
SamWhitedI don't see why interoperability would be better or worse with an XML based wire format vs. a plain-text-with-magic-characters based wire format
moparisthebestI'm saying like xmpp setup is like A (client) -> B (server) -> C (server) -> D(client)
moparisthebestB only needs to know it's coming from A and going to C, not about D, C only needs to know it's coming from B and going to D, not about A
SamWhitedI'm actually worried that making it more extensible and "future proof" as you put it will be a bad thing here. It's not necessary and I suspect will just lead to feature bloat in the long run
jonaswSamWhited, when you start to define new meta-characters or obsolete existing ones, the messages are interpreted differently.
andrey.ghas left
moparisthebestand any content besides those specific routing instructions can be encrypted e2e so only A and D can see them
SamWhitedjonasw: that doesn't bother me at all
jonaswSamWhited, I know.
jonaswthat’s what worries me.
SamWhitedthat's already what happens when I add a new smiley or something, and it's a minor anoyance at worst
Ge0rGIt's a consistent annoyance.
SamWhitedTrue, but still a minor one.
jonaswI don’t see why we have to buy that minor annoyance which is simply going to happen (I don’t approve of messengers which replace text with emoticons either, by the way) if there are alternatives.
danielfwiw i do see the benefit of jonasw approach. but i don't see me implementing this anytime soon due to the omemo problem
SamWhitedIf there were good alternatives I'd agree, but I think the trade offs on the alternatives are worse.
SamWhitedAnd if it weren't such a minor problem that doesn't affect most people
Ge0rGdaniel: fix omemo then...
jonaswSamWhited, let’s turn this around, what’s your problem with my approach?
danielGe0rG, i do make some money with Conversations. but unfortunatly not enough to go down *that* rabbit hole
SamWhitedjonasw: It's a lot more complexity. How does it interact with message editing, for example?
SamWhitedHow does it interact with OMEMO, OTR, etc? Does it leak information?
jonaswSamWhited, do you mean message correction?
SamWhitedyah, that one
jonaswmessage correction is clear on that one: the new <message/> replaces the old
jonaswso you’d include the markup again.
Ge0rGSamWhited: the corrected message needs to have its own markup xml
SamWhitedah yah, that one actually makes sense I suppose
jonaswSamWhited, interaction with OMEMO and OTR etc. is at least better than with XHTML-IM (instead of leaking the full plaintext (hi pidgin!) or having no markup at all, you can leak only the markup or have no markup at all. that’s a step forward or so...)
danielGe0rG, also my last attempts in starting a discussion on stanza content encryption didn't go anywhere
Ge0rGSamWhited: also you can just strip the markup and still have human readable body
SamWhitedGe0rG: You can do that in either case
Ge0rGAnd screen reader readable
moparisthebestor, with SamWhited 's approach, you can do nothing and still have a human readable body
Ge0rGAnd no false positives
Ge0rGmoparisthebest: for a limited subset of "human readable"
jonaswdaniel, can you point me to it? I can’t find it in my local archives.
jonasw(a subject line or keyword to search for will do)
moparisthebestworks for everything else so
SamWhitedAnyways, I'm not saying that this is bad, just more complex and I don't see any significant benefit that's not outweighed by the disadvantages.
moparisthebestI might have just missed it but is > 1 index/character with respect to start/end or 4 ?
jonaswmoparisthebest, 1.
jonasw"XML character data" => entities are already decoded
jonaswsane XML parsers won’t hand you entities anyways
Ge0rGBut it seems that different users apply different weights to different disadvantages
moparisthebestI saw XML character data, I didn't know what that meant though
jonaswmoparisthebest, in short, that what your XML library hands you when you ask for an elements text.
moparisthebestthe main disadvantage is all clients have to implement this or any formatting is lost
moparisthebestwheras if I say something *really* important
moparisthebestyou get it regardless
danieljonasw, mail is in the 'omemo discussion summary 2017' thread and my particular mail is from june 22nd
jonaswmoparisthebest, that’s the better case I think
jonaswmoparisthebest, with Message Styling, all *sending* clients have to implement it or their message may be incorrectly and unexpectedly formatted
edhelashas joined
moparisthebestno, sending clients don't have to implement it at all
nycohas joined
jonaswif we’re going to have incompatibilities between markup interpretation, I prefer them to be vanishing markup instead of markup which apperas out of nothing
moparisthebestno one is using a WYSIWYG editor to bold something
moparisthebestthey are just typing *bold*
jonaswmoparisthebest, they do, if they don’t want their line which starts with "> " to be interpreted as blockquote.
jonaswmoparisthebest, you’re assuming that all clients are operated by humans.
moparisthebestI feel like a broken record here, but again, everything has been doing it since way before xmpp
moparisthebestso people are used to it, and it's fine
jonaswanyways
jonaswas promised, heading to bed
moparisthebestemail for example, IRC for another
Ge0rGmoparisthebest: and the sending client can convert that to bold in the input line and send well defined wire format. Or you can press undo and send ** instead
SamWhitedYah, it seems like it's been firmly in the "good enough" category for many, many years.
moparisthebesthmm then I have to care though
danieli can see myself adding jonasw markup to outgoing unencrypted messages on top of SamWhited's styling
danielit doesn't hurt
ArcTobias: IRT xep0385, I have an objection to table 2. First and most notable, Opus is an IETF standard for audio and was left out entirely.
moparisthebestI do immensly prefer jonasw's solution as opposed to duplicating the text in a different element
SamWhitedI agree with that
moparisthebestin fact, add all the xhtml-im features to that and publish
SamWhitedI do not agree with that and see it as the most significant downside to the spec
moparisthebestit feels like a mandatory whitelist kind of
moparisthebestI suppose mr. evil could still include <script> directly in the body
moparisthebestbut I guess that's always a danger for a dev dumb enough to .innerHTML it
jubalhhas left
Ge0rGAnd then a client needs to put styling into the body, markup into a related xml and add xhtmlim
efrithas joined
moparisthebestI don't think so
jjrhhas left
goffihas left
andrey.ghas joined
Guushas left
andrey.ghas joined
andrey.ghas joined
pep.moparisthebest, what you type as your input doesn't have to be what the client sends verbatim. If you want to use markdown (or whatever else, poezio uses ^C<key>) as your input format, fine. But don't send that on the wire and let the receiving client decide on what/how to display it
andrey.ghas joined
moparisthebestpep., I get it, and totally agree for complicated formats, but don't overcomplicate something simple that has existed since before xmpp
pep.How does that change anything to what I just said above. As a client I still want to decide what I display
andrey.ghas joined
jjrhhas left
moparisthebestpep., do you understand that I meant to emphasize *this* in my message though?
pep."it's always been how we've done and it works fine". I don't have an example offhand but I'm sure this is not the best argument out there
moparisthebestor do you need some fancy wire protocol to understand that?
moparisthebestfor the limited subset of markup in that one particular xep, it works perfectly fine
pep.Still, what if I don't want to understand it, what if I can't understand it
moparisthebestif you want to get more complicated, do so in some other way
pep.As it's been said on the list already
andrey.ghas joined
moparisthebestthen I guess tough?
moparisthebestat least you had a better chance than if you didn't get ** because your client didn't implement fancy-new-xep
pep.Nice for an eXtensible protocol
jjrhhas left
andrey.ghas joined
sezuanhas joined
jjrhhas left
Alexhas left
andrey.ghas joined
pep.SamWhited, Example 8, isn't the nested version missing a space?
Guushas left
Guushas joined
pep.Or maybe the sentence above can be reforumlated a bit
SamWhitedpep. no, I need to clarify that. If you parse the outer quote as a block, then parse the inner quote then it's the "start of the byte stream"
pep.Or maybe the sentence above can be reformulated a bit
pep.k
SamWhitedat least, that's how it ended up working in my little parser which recursively parses inside blocks, and it seems sane
SamWhitedI was debating if I needed to be strict about specifying that though or if that's just going to confuse people. Overspecifying is sometimes as bad as underspecifying.
pep.But then some clients might render "> > " different from ">> "
danielSamWhited: the XEP could probably use a few more complicated examples at some point. Like something people could copy past into their unit tests
SamWhiteddaniel: agreed. I started on a unit test suite as well which I'll push when I push out my implementation
danielBut we should nail down the syntax and test everything a little bit more before going through the troubles
SamWhitedIndeed
SamWhitedConveniently, the commonmark parsing rules are basically the same (I mostly stole them), so you can test things (albeit with slightly different characters) using their tools more or less
moparisthebestpep., point is people have typed like this since before xmpp, type like this now, and will type like this later, whether someone standardizes the rules or not
moparisthebestwhat exactly is the problem with it? not enough XML?
jubalhhas joined
Zashhas left
SamWhitedI think I'm going to move the block/span stuff into implementation details and make that non-normative. If a few clients have incompatible edge cases it's no worse than today (where lots of clients effectively implement this slightly differently), then I can still provide guidance without overly limiting people. </thinking outloud>
pep.moparisthebest, you pollute the plaintext. As people have said already:
it's not easily interoperable. Once you say italic is not // not __ anymore, what happens to __? people will still continue to display both because "tough luck"? (as you say)
Not easily extensible. Adding more and more meta-characters removes choices from the selection of characters I can use to type text.
Maybe for you it is "human readable", and for others in your own circles, but that's the extent of it. You are not taking into account other people, bots, you are not taking accessibility into account.
SamWhited"not easily extensible" is a feature.
pep.So you're fine cluttering client markups until the end of times
SamWhitedyes, although I wouldn't phrase it that way
danielhas left
moparisthebestright you don't want it extendable at all
moparisthebestit's a de-facto standard anyway
pep.no it's not
pep.I was reading just above Kev uses // for italics
pep.You are using __
moparisthebestthis happens and will happen regardless of if we standardize
pep.moparisthebest, no that's the point
moparisthebestyea, I don't think it matters, I also use /italics/
pep.if we standardize it shouldn't happen
moparisthebestgajim supports that by the way
pep.That's the whole point
SamWhitedpep. I think he meant that most things are already using some kind of indicator in the text and people will keep doing that. Not the specific indicators
Guushas left
moparisthebestyes
moparisthebestI mean most people write like that anyway, regardless of any client support
moparisthebestand then also lots of xmpp and non-xmpp clients mark it up based on those
pep.SamWhited, agreed, people have been using that, and as I said above I wouldn't mind the client using it as input, but I really not keen on sending that on the wire
Guushas joined
moparisthebestthat's fine for something that isn't already widely used I guess
SamWhitedMy IRC client, one of my XMPP clients, my email, and probably other things I'm forgetting already send that on the wire and it works pretty well.
moparisthebestand as you said slack and whatscrap
pep.No, it works for you and your circles, because they know
moparisthebestI thought whatscrap was for the mom's of the world
SamWhitedIt also works for every non-technical person who uses whatsapp that I know (and that's a lot more than the technical people in my XMPP circles)
pep.Slack people don't know, Mattermost people don't know
pep.They only have to click
pep.normal people don't use IRC so I think I can safely discard that one. Or they use some fancy client that handles that for them, still you rarely see non-technically people willingly use it, Same for email actually, it's not the same usage at all between technical and non-technical people
pep.Non-technical people often send html and there you have rich content
la|r|mahas left
pep.(and fancy colors, eww)
moparisthebestare you saying XMPP has more users than email and IRC ?
Ge0rGNon technical people don't use the markup characters in normal use, because they don't need to paste directory paths nor math formulas
moparisthebestbecause uh, seems wrong
pep.moparisthebest, not "more"
pep.Different kind of users I believe, or at least aiui that's a target for the XEP
Valerianhas left
pep.Because Slack and Whatsapp are cited a number of times
moparisthebestwhat kind of users are you trying to target who's needs aren't met? I'm confused
moparisthebestbecause you mentioned IRC which is more technical and whatsapp which is the exact opposite
moparisthebestboth implement this same thing
pep.No I'm just trying to extrapolate who you are thinking the XEP is targetting
pep.I didn't mention IRC, Sam did
moparisthebesteveryone on the internet does this type of thing
moparisthebest[04:48:57 PM] pep.: normal people don't use IRC so I think I can safely discard that one.
pep.Yes, read a sentence above now
pep.SamWhited> My IRC client, one of my XMPP clients, my email, and probably other things I'm forgetting already send that on the wire and it works pretty well.
moparisthebestI've never heard of an IRC client with a WYSIWYG editor
moparisthebestthey don't even have passwords without messaging a bot
pep.maybe you don't know about sasl, but that's how of the scope for tonight
Valerianhas joined
moparisthebestthat's a super recent extension not everything implements though :)
moparisthebestand server-side, it still gets passed through to the nickserv bot
danielhas left
SamWhitedThis went really off the rails in the time it took me to discuss something at work and then come back :)
SamWhitedI'll be interested to read the backlog and see how it got to SASL
moparisthebestbottom line is if it's good enough for email, IRC, and whatsapp, then it's fair to say it's good enough for xmpp
pep.SamWhited, same here :/
moparisthebestbecause that covers the gamut of *all* internet users
KevSamWhited: No, it wouldn't.
KevNo, you won't, rather.
moparisthebestI'd love to hear about the internet user that doesn't use email or whatsapp
KevYou might think you will, but it'll be a big disappointment when you get there.
jjrhhas left
pep.Kev, :)
SamWhiteddrat
Guushas left
KevOTOH, I just found a presence leak in 6121, so that's nice.
SamWhitedoh fun
Guushas joined
andrey.ghas joined
KevActually, it's not a presence leak, just an inconsistency. Drat.
danielhas left
andrey.ghas joined
danielhas left
pep.SamWhited, otherwise, if you have time to answer my direct reply to your comments that'd be nice
jjrhhas left
lovetoxi could live with both approaches, if Sams approach is *really* simple, so nothing fancy like lists and stuff, keep it simple and readable even if a client doesnt support it
SamWhitedpep. direct reply?
andrey.ghas joined
pep.like the small block of text before moparisthebest barged in
moparisthebesthey I've been here the whole time :P
moparisthebestoops :P was sent as text and rendered as a smiley, need a xep and new wire format
jjrhhas left
SamWhitedpep. I don't see it
lovetoxjonasw, approach i like because i dont need to write parsers for that, seems simple and its more of a replacement for xhtml
SamWhitedPlease hold, asking a friend who knows nothing about computers "How do you make text bold in Whatsapp?" to see what they say
danielhas left
pep.SamWhited, yeah, one example won't discard all of this. I do agree I don't have statistics on this, but neither do you
pep.SamWhited, yeah, one example won't discard all of this. I do admit I don't have statistics on this, but neither do you
marchas left
lovetoxSams approach also seems like a: Many clients do this anyway so lets make a XEP out of it
moparisthebestyea, why not?
danielhas left
Guushas left
andrey.ghas joined
edhelasbecause sometime it's not because a lot of persons are doing something that it's good ?
danielhas left
lovetoxi dont really feel that this needs a xep, a client can show this that way and have a config option to turn it off like gajim has for proably a decade
Guushas joined
SamWhitedlovetox: I more or less agree with you, but I was told that we can't deprecate XHTML-IM until there's an alternative (and maybe if nothing else this will introduce a little consistency or broaden support for simple formatting)
jjrhhas left
SamWhitedpep. in that case if you're allowed to argue with no data and I'm not allowed to at least ask around, I'm not sure how you want me to respond to that. I don't think it's a problem, people use whatsapp, it does this. I don't think it has a bold button on Android (unless they've added one), and people still send bold text.
danielhas left
SamWhitedThe people who really, really won't understand this aren't likely to use it, so no harm done. Unless you can demonstrate somewhere with a high rate of false positives where it would cause confusion?
danielhas left
SamWhitedOr, alternatively, people who really won't understand this can use a client with a bold button.
pep.re: no data, fair enough.
pep.Then I don't understand why you absolutely want to pass this on the wire
lovetoxi dont feel strong as other people about your approach because i simply think it will change nothing
lovetoxclients use this formatting already, and will conitnue
danielhas left
SamWhitedpep. because it's less complicated than adding an entirely new wire format, does what clients already do and what (I suspect, with limited data as you pointed out) people are already used to
SamWhitedIt also follows a convention that's been in use for a long time across multiple types of media
danielhas left
lovetoxi think people will likely accept it more if its a : lets write down the status quo
danielhas left
lovetoxbut if you mean, lets extend it later and add all kinds of stuff
lovetoxthen i think jonas approach is better
SamWhitedI specifically want it to *not* be extended later with all kinds of stuff.
danielhas left
pep.SamWhited, why?
jerehas joined
SamWhitedpep. because that's the trap we always fall into: make everything as complicated and as extensible as possible. This leads to incompatibilities between clients, makes things harder to implement, etc.
andrey.ghas joined
lovetoxpep. because you get more and more styling elements into the plaintext
SamWhitedI want styleing, not layout
SamWhited*styling, even
pep.SamWhited, I am not willing to sacrifice <body> over a "I don't want to complicate things", I don't think that's something we can come back from
SamWhitedpep. it's already something people are doing, you're not changing or sacrificing anything.
SamWhitedIt works today, it's simple, people are used to it. That's "good enough" as far as I'm concerned.
danielhas left
Guushas left
Valerianhas left
Guushas joined
edhelasjonasw interesting approach :)
pep.I definitely prefer it to Styling as well. I find the whole thing futile in the first place, but I understand the security concerns and I think jonasw's proposal covers it
ArcSamWhited: I think jonasw's approach is overcomplicated, however, it has some interesting side effects.
bjchas left
nycohas left
Arcim trying to remember it, but there was a XEP published about a year ago (?) that allowed you to updated a previous message
nycohas joined
SamWhitedArc: we briefly discussed the message replacing one, you'd have to fully replace the message and the new one would have to have its own offsets
danielhas left
SamWhitedUnless this was something different?
Arcwhat if it only updated the markup, or added to it.
Arcsomething like this would have to survive numerous tests, such as whiteboarding
bjchas joined
Arcyours is obviously simpler, and I agree that its a good thing.
Arcfrankly i think this whole issue is a bikeshed that's only going to rage on until everyone's exhausted and the issue is dropped again
danielhas left
Arcim sitting next to our UX guy and he's hard eyerolling at the whole issue
pep.I think that's just a waste of time and we have other more interesting things to tackle
Arci think tackling xhtml-IM is important. but yes there's so many other issues.
Arcthe construction workers still need their bikeshed.
SamWhitedYah, really this whole thing only exists because for some reason people think we can't deprecate XHTML-IM until there's something else vaguely similar
moparisthebesthas joined
Arci like that inline images are no longer included in either proposal.
pep.SamWhited, I think deprecating XHTML-IM is not the answer in the first place and that's what started this whole holy war.
Arcpep.: there's strong feelings on either side of it. but the core point remains, until someone has solved the core issue with xhtml-im it is *not* worth user security for the rarely used features it offers
Arcxhtml-im has had a decade of real world use, and the security issues are yet to be solved. most don't even try. that's the issue.
SamWhitedIndeed :(
pep.Well if they don't even try they're not going to try much more with other implementations. But I've already been told to shut up for whatever reasons
SamWhitedpep. that's why we need specs that just don't have the same fundamental flaws, so that people who just don't try (or who do try but make a mistake) are less likely to shoot themselves in the foot
Arcor in this case, shoot all their users in the foot.
pep.Then I guess XHTML-IM is not the only XEP you should tackle, I hope you have time for the rest of every single XEP that tries to display something to the user
Arcwe're getting slaughtered on the UX front.
danielBy the way. Conversations now supports code blocks as well. The next stable release will probably be tomorrow or the day after. And then we will get some real world feedback on the styling thing
pep.And more cluttury interface :( I already hate the blockquote thing
pep.When I don't explicitely ask for it
Arcpep.: i agree there are many. and I think there's a large interest in addressing them, xhtml-im is just a low hanging fruit with massive security issues
pep.I think jonasw's proposal answers the security concerns fairly well though
pep.It may still be improved, but that's a step forward
SamWhitedpep. yes, both address the concerns with XHTML-IM as far as I can see.
ArcI don't dislike his proposal. I see merits in it. We're not going to resolve it today, there'll be some time to consider and discuss.
SamWhiteddaniel: nice, that was quick. I still haven't built the branch so maybe I'll just wait now
jubalhhas joined
pep.Arc, as you said earlier, I only see this resolve itself when everybody gets tired of it and one of the sides gives way
pep.(or maybe it wasn't exactly what you meant)
Arcthere's a number of young XEPs now that deal with ranges demarking substrings within message bodies
sonnyhas joined
Arcpep.: not exactly. you and I? we're not client authors.
Arcdaniel is. he and others have the final say, regardless of whatever is published in the XEP. ideally the XEP that gets promoted reflects the consensus that evolves out of this discussion.
pep.I liked goffi's point btw, against the "You can have the plaintext version differ from the rich content if you include both".
pep.Arc, well he gets the final say for his client
pep.And his client only. That will probably influence other clients though, or the war might continue to rage, I don't know
Arcpep.: do you author a client?
pep.In the process of
Arcoh neat, what platform is it for
Arceverything we're working on is web-based, tho i have next to no involvement with the frontend.
pep.We're still a bit far to say that, I guess it'll run on whatever the authors use primarily. The code is in Rust, I'm not sure about the frontends yet, we're sorting the xmpp stuff out first
Arcgreat to hear about someone using Rust, its a very cool language
pep.It is indeed :)
SamWhitednice; my little toy client is also in Rust, but I've never gotten it far enough along to want to publish it.
Arcits a shame they haven't trimmed it down for embedded use tho, I'm still waiting on that
pep.Arc, there are quite a few use cases for it in embedded already from what I hear, but I have no experience in it
SamWhitedArc: you can actually build without the standard library which is where all the stuff that relies on the OS lives and you end up with a minimal core library which works great on embedded hardware
ArcSamWhited: oh really? do you have a link to that?
SamWhitedyah, just a moment
pep.You heard about TockOS? Also as SamWhited says, have a look at https://github.com/japaric/xargo
Tobiashas joined
SamWhitedI'm not sure if there's a section in the rust book yet, but the stripped down version of the standard library with no OS stuff is called "core"
pep.There's a guy that's quite keen on doing embedded stuff in the Cambridge Meetup
SamWhitedArc: https://doc.rust-lang.org/book/first-edition/using-rust-without-the-standard-library.html might help
SamWhitedObviously all safety guarantees go out the window at that point :)
SamWhitedRust is a cool language, I wish I had more reason to use it day to day
pep.I wish I had more opportunities, reasons I have plenty of :P
ArcSamWhited: things like bitpacking and hashing routines are things i regularly optimize for
Arcwell. "regularly" is an overstatement. but still.
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
Tobiashas joined
Valerianhas joined
la|r|mahas joined
la|r|mahas joined
la|r|mahas joined
jjrhhas left
ArcSamWhited: move to Portland, lets give you reasons to use it daily :-)
SamWhitedArc: I can't, I watched the TV show and now I can't go to Portland without laughing uncontrollably
SamWhitedAlso, I'm reasonably sure that it's a fictional place and that no one actually lives in Oregon.
ArcPortlandia is unfortunately closer to the truth than any of us are comfortable with, but it is a real place.
Tobiashas joined
SamWhitedIf that show is any indication it actually reminds me a lot of Austin
ArcI've heard that as a comparison, but Portland is certainly weirder. For example, Austin doesn't have nude beaches that are a central social spot to just hang out
lovetoxhas left
vanitasvitaeIs anyone else getting the permanent notification that Flow isnt typing anymore in conversations?
Arcor this (NSFW) https://pdxwnbr.org in which naked people basically take over the city, walk into a random convenience store or cafe and you're likely behind someone in their birthday suit
SamWhitedArc: hah, I've heard of that, sounds… interesting.
ArcCTRL-H held an after-party this year where naked people took over the hacker space
SamWhitedIn a hacker space full of laiths and laser cutters a naked after party just seems dangerous …
Arcthe main room is a big coworking space and lounge. that's where I am now. all we have here is an occulus rift and a few 3d printers, totally fine for parties