dwdYeah, kind of wishing this were a more restrictive licence.
Marchas left
afrogeekhas left
stpeterhas joined
afrogeekhas joined
adiaholichas left
Marchas joined
GuusHow are you feeling today, dwd ?
j.rhas joined
dwdTerrible. But nothing that can't be fixed. Doctors coming later this morning.
Maxhas left
Maxhas joined
afrogeekhas left
Maxhas left
Maxhas joined
mathijshas left
afrogeekhas joined
mathijshas joined
Maxhas left
ralphmI hear Guus lost 3 kg, so look on the bright side :/ Hope you feel better soon.
Maxhas joined
Guus(almost 4, actually)
mathijshas left
mathijshas joined
GuusI hope you feel better soon, Dave.
Guuswhen did this start? Only after you got back?
afrogeekhas left
Maxhas left
Maxhas joined
stpeterhas left
j.rhas left
mathijshas left
mathijshas joined
mathijshas left
mathijshas joined
afrogeekhas joined
Steve Killehas left
stpeterhas joined
afrogeekhas left
afrogeekhas joined
mathijshas left
mathijshas joined
afrogeekhas left
mathijshas left
mathijshas joined
afrogeekhas joined
stpeterhas left
afrogeekhas left
afrogeekhas joined
mimi89999has left
mimi89999has joined
afrogeekhas left
lskdjfhas joined
afrogeekhas joined
mimi89999has left
mimi89999has joined
stpeterhas joined
afrogeekhas left
adiaholichas joined
afrogeekhas joined
mimi89999has left
mimi89999has joined
afrogeekhas left
afrogeekhas joined
stpeterhas left
afrogeekhas left
APachhas left
eevvoorhas joined
APachhas joined
pdurbinhas left
stpeterhas joined
debaclehas left
Dele Olajidehas joined
stpeterhas left
larmahas left
debaclehas joined
stpeterhas joined
eevvoormy colleague lost purse and smartphone on the way back of FOSDEM. He travelled the whole monday due to lost identity. But he is healthy.
stpeterhas left
pep.I was surprised at some point because my bag had been moved from one place behind the booth to another part of the booth (behind the Matrix people!!) and under a pile of bags :x
ralphmpep., you're welcome. I think I've made it clear the lounge was not a bag storage facility, so I regularly moved stray bags there.
pep.I probably wasn't there when you said that, but ok
ralphmI think I mentioned it at the Summit, too, but no worries.
intosiThat's something we say every year, in quite some abundance.
ralphmMost of them were from the Matrix people.
pep.intosi, not all of us have been involved for the same amount of time
goffihas joined
pep.Also that's a FOSDEM-specific thing, because I've been running other conferences and it usually works well that way :)
ralphmHaving bags behind a booth is typical indeed, but destroys the concept of a lounge. That's why I mentioned it at the end of the summit.
ralphm(there were other factors that caused the lounge to not work this year, but that's a different discussion that I don't have time for to go into now)
stpeterhas joined
eevvoorhas left
stpeterhas left
larmahas joined
larmahas left
larmahas joined
Kevhas joined
stpeterhas joined
pdurbinhas joined
pdurbinhas left
Marchas left
Marchas joined
stpeterhas left
eevvoorhas joined
stpeterhas joined
j.rhas joined
stpeterhas left
j.rhas left
Guushttps://xmpp.org/extensions/xep-0424.html section 5:
> Some clients may have been offline while the retraction was issued. The archiving service therefore MUST store the retraction message, regardless of whether the original message is deleted or replaced with a tombstone.
This adds a server-sided restriction to this otherwise client-sided XEP, which I dislike. If the MAM implementation on the server does not follow this, retraction is very flaky (MAM retrieval will return the original message, but not the retraction). However, server support is not clearly signalled for in the XEP (service discovery examples imply that only partners are queried). Am I missing something?
Guus(as the retraction message has no body, that message might not be archived by MAM implementations that are not aware of XEP-0424)
pep.Maybe adding a store hint to the XEP would help?
xsfhas joined
stpeterhas joined
xsfhas left
xsfhas joined
Dele Olajidehas left
Dele Olajidehas joined
flowbut aren't hints deprecated?
larmaflow, it's deferred
Ge0rGbut it was very much disliked by the Council that decided on it last time
j.rhas joined
larmaThere is no replacement for it other than fallback bodies which is stupid for things like retraction really
lorddavidiiihas left
lorddavidiiihas joined
ralphmlarma: fwiw, so is MAM itself (deferred) :-D
Ge0rGthere were two issues with Hints: a) you can't properly add hints later on; b) each hint has implications to a certain other XEP, and thus should better be described in that "master" XEP
larmawhat do you mean by a)? And I agree to b) but that just means we need to update MAM instead of saying we don't do hints anymore
Ge0rGlarma: 334 contains the exhaustive list of hints. If you add a new hint, you need to version-bump Hints
Ge0rGand if you don't version-bump, you can't have hints with new semantics that require special processing
ralphmwhy?
MattJor just make another XEP with whatever other hints
Ge0rG"Hints 4, this time it's serious"?
pep.MattJ, same issue?
MattJWhat issue?
MattJThe whole point is btw that they are "hints", it's meant to not be a disaster if they aren't followed
pep.Not saying I understand what Ge0rG is saying, but bumping a XEP or creating a new one is technically equivalent in general
MattJThey are also meant to be semantic, rather than tied to specific protocols
Ge0rGpep.: with a new XEP, you don't auto-deprecate the old one, so you end up with five different Hints XEPs that all contain different hints
MattJSo no-copy is not tied to Carbons, but any copying-to-other-resources mechanism
pep.Ge0rG, even better!? :p
larmaUsually the hint should be in the XEP it belongs to, but now MAM and carbons don't have hints and those in 334 are widely supported and thus a de-facto standard. Also moving <store /> to MAM would mean that any other archiving XEP would need to redefine it and we'd need two hints. So at least for <store /> and related hints we should stay with the current
Ge0rGpep.: so why not have each hint in the XEP that contains the actual processing semantics that are affected by the hint?
Ge0rGlarma: Carbons do have their own "hint"
pep.Ge0rG, sure. It's not what I was replying to
xsfhas left
xsfhas joined
Ge0rGbut I think that Carbons and MAM are actually good causes to fix message routing and persistence semantics, i.e. IM 2.0
larmaWe started this discussion about store hint 😉
Ge0rGmsg to bare --> persistent, copy-everywhere
message to full --> ephemeral, no Carbon, no MAM, no offline store
ralphmWe at some point tried to have comprehensive processing rules (https://xmpp.org/extensions/xep-0079.html, AMP) and that was a bit of a failure.
xsfhas left
xsfhas joined
xsfhas left
xsfhas joined
xsfhas left
Guus> There is no replacement for it other than fallback bodies which is stupid for things like retraction really
I don't know if this is so stupid. It would make the retraction visible even to clients that do not support it - which makes a huge difference in semantics. Additionally, adding such a body has the side effect of the retraction having a better chance of being archived by existing MAM implementations.
larmaGe0rG, I'd be fine with that, but legacy clients do send to full jid so we need to handle them (if we don't want a new IM network that is independent of the current)
xsfhas joined
pep.Guus, how do you want to show retractions to clients that don't support it?
pep."The message you're still seeing above -- because I don't support retraction -- has been retracted" ?
stpeterhas left
Dele Olajidehas left
Guuspep. basically. I'd include a copy of the retracted body, prefixed with 'retracted' or something.
Guusit can be ugly
Dele Olajidehas joined
Guusthat, if anything, motivates client developers to add support. 🙂
pep.It is to me, and also useless
Ge0rGlarma: yes, there would be tagging of IM 2 zones, and conversion from / to hints or somesuch at the 'border'. Incidentally, the same rules as discussed will apply there.
Yagizahas left
pep.Guus, you'd be helping the spammer to spam :P
lorddavidiiihas left
Yagizahas joined
Ge0rGGuus: that's a nice reminder to screenshot the messages!
GuusDefinitely not useless. A client that receives a retraction, but does not support _or_ show it through a fallback, is dangerous.
xsfhas left
xsfhas joined
Guusboth chat participants will have a very different understanding of the correspondence state.
pep.Guus, how is it dangerous
lorddavidiiihas joined
waqashas joined
pep.I think we get into social territory, and I'd rather not
GuusIf I send you a bunch of messages, and retract one, and I am not aware that your client does not display the fact that I retracted that one message, very nasty stuff can happen.
larmaGe0rG, so we do need hints, we just want to get rid of them longerm. Can we please stop with longterm being a reason to do stupid things now?
pep.Guus, I could say the same of every single feature that's socially used in context.
pep.I still use presence information and talk about it sometimes, should I put that as fallback body somewhere?
Guusno, this is not a social thing
Guusthis is a semantic thing
Ge0rGlarma: what if we want to use longterm to not do stupid things now?
Guusyou, as a receiver, missed the fact that I, as the sender, changed the semantics.
pep.You removed a spam message for convenience. It's fine if I still see it.
Guusspam, sure
pep.Or you removed information that I wasn't supposed to see, well too bad.
Guuswhy would I delete my own spam, btw?
pep.Not your own
moparisthebestalso true of any "styling" XEPs right? changed meaning and all that
Guusyou can only retract your own messages with that XEP, afaik.
pep.Ah ok I had moderation in mind, similar case
larmaGe0rG, we agree that longterm we do the IM 2 network without (or with less) hints and that the IM Legacy network that we are using now needs hints, so why is that a reason to deprecate hints when it is needed for the network we use now?
GuusThe fact that the receiver does not get that the information that was not ment to be sent is removed, makes the sender unaware of the fact that it was not ment to see that information.
Guusthat really has very nasty real-world problems.
xsfhas left
xsfhas joined
larmadeprecation before replacement sounds like a stupid concept for me
GuusIf will lead to situations where people do not _trust_ the messages they receive from XMPP.
Guusand that is killing.
Ge0rGlarma: I told you the reasons I remember for Council not advancing hints.
pep.I don't really agree with this assessment
Guuspep. suffer from it once, and you will. Trust me on that one.
pep.[citation required]
larmaGe0rG, I wasn't specifically talking about you, but more about what seems to be a general thing in XSF (there also were voices to deprecate OMEMO without replacement etc)
pep.- I don't like XXX
- Oops that wasn't for you
- retracted: I don't like XXX
pep.:P
Ge0rGlarma: regarding Hints, I even do agree with the argumentation
Guuspep. now imagine that you didn't type "- Oops that wasn't for you"
pep.Guus, so you see twice "I don't like XXX" in clients that don'T support it?
Guus(why would you type that, if you expect the receiving entity to receive the retraction)
pep.Very much fixing the issue
GuusYou see:
- I dont like XXX
- RETRACTED: I dont like XXX
which is ugly as hell, but at least has the correct, intended, semantic value.
pep.How does that help with anything
Dele Olajidehas left
pep.Now you've seen twice that XXX (potentially YOU), I don't like.
Dele Olajidehas joined
GuusFor clients that do not support the XEP, the message has been displayed at least once anyways, so there's little additional harm.
xsfhas left
pep.For clients that do support it the message may be removed, so the fallback is useless
GuusIf you don't include the fallback message in the retraction, the receiving entity might be completely unaware that the message is retracted.
GuusThose would only see:
- I don't like XXX
Guus(no retraction)
andrey.ghas left
larmaGuus, same as if the retraction message got lost 😉
larmalegacy clients might not be doing MAM
Guusyes, so make sure that the retraction message never gets lost, by adding a fallback body. That way, XEP-support clients will remove/hide the retracted message, while clients that do not support the XEP can at least be trusted to 'receive the meaning'.
Guusthis is not a MAM issue.
Guusthe fact that it also makes it more likely that MAM implementations might behave a bit better is a nice side-effect.✎
Guusthe fact that it also makes it more likely that existing MAM implementations might behave a bit better is a nice side-effect. ✏
larmaif my legacy client does not do mam/carbons it is likely to happen that this client does not receive the retraction message at all
pep.I really don't like how we've been shoving everything into <body/> lately. This is of course not as bad as 393, as there would be a tag alongside (and hopefully the message would only be used for this), but it seems to be a trend anyway that everything and anything needs to appear in body as well
larmalet's call my legacy client pidgin, which apparently is the most popular XMPP client
pep.It's like we're trying to write protocols on top of XMPP's <body/>
Guuswe can think of all kinds of situations in which this still would not work - but at the very least, it'd be a considerable improvement of not doing a fallback.
Guuspep. I'm very much with you that this is ugly.
Guusbut I think it is necessary.
adiaholichas left
adiaholichas joined
pep.I don't
Guusa situation in which a message was retracted by the sender, without the recipient being aware of it, must be avoided.
larmaGuus, I believe that those clients that work proper today (= not Pidgin and other legacy clients) will support retraction soonish once it's a stable standard
Dele Olajidehas left
Guuslarma: we cannot have an ecosystem that is intentionally broken for some clients, and which is constantly waiting for the more modern clients to pick up the newer features (being broken untill they do).
Dele Olajidehas joined
Guuswe must have a decent fallback.
Guusthat's why it's called just that, a fallback.
larmaGuus, we already broke Pidgin effectively
pep.Also these fallback things force any implementation to support things they wouldn't want to support
GuusThey don't force you to do anything
pep.In a way yes. Now you're sending me that ugly RETRACTED: foo
pep.Or > foo\n<reaction>, or.. some other fallback
GuusI stand by my point that it is so much better to show that ugly message instead of receiving a retraction that your client completely ignores.
GuusThat's simply dangerous
vanitasvitaehas left
xsfhas joined
vanitasvitaehas joined
Guusideally, the recipient shouldn't receive the retraction at all, of course, using service discovery. But how does that work with a user that uses two different clients, of which just one supports retractions?
pep.Yes the "send everything to all clients because MAM/carbons" argument
xsfhas left
xsfhas joined
xsfhas left
GuusI need to get back to work.
xsfhas joined
larma(completely unrelated) I started to look into issues of XEP-0385 because of Stickers. My proposed changes are now rather substantial (I'd even want to change the title), should I maybe better make a new XEP instead?
pdurbinhas joined
calvinhas joined
calvinhas left
calvinhas joined
xsfhas left
andrey.ghas joined
flowlarma, i'd present the "new" xep the community and potentially council and see if there is a clear opinion on that
flowalso maybe reach out to Tobias the xep385 author
pdurbinhas left
Tobiaslarma, what kind of issues?
stpeterhas joined
j.rhas left
larmaTobias,
- Focus on media, not generic for any file type
- Mixed content, body can not be used as a fallback
- Depends on jingle file transfer for the metadata
- Uses underspecified URIs
- Uses XEP-0372 in underspecified fashion
- Number of MUSTs that seem odd to me (must support http file upload and jingle ft, must specify description, media-type and hash)
Tobiaslarma, media basically is any file format, not? i mean images, photos, videos, pdf, etc.. I don't see it limiting the kind of data you share...it only makes recommendations for video/images with regard to what should be supported so there is some interoperability.
Tobiasunderspecified URIs?
Tobiasyou mean these https://tools.ietf.org/html/rfc6920 ?
larmaIt says "inline media sharing" which kind of implies that I can't use it to share an executable for example. The use cases literally only say how to share and receive a photo
larmaI was referring to the jingle pub uris which can hardly be used for file transfer because they just share a jingle session, but don't specify what those jingle sessions actually are. The client has to guess that it probably is the latest iteration of Jingle File Transfer
larma(my proposal changes it to use the jinglepub element defined in XEP-0385 which allows providing a jingle description element)
Tobiasprotocol wise there is nothing limiting the kind of things you can share, might as well share exe, zip, .iso images or whatever.... sure maybe examples are missing but i just went with the most common use case, of sharing audio/video/images.
Tobiasdefined in 385 or 358?
larma358, sorry
Tobiasah..ok
larmaI am not saying those can't be addresses in 385, but the changes are rather significant. Also the fact that you could use it for every file type IMO doesn't change the intention. The fact that there are SHOULDs for media codecs is an issue for a generic file transfer XEP
Tobiasthe SHOULDs are there for interoperability in user interface
larmaTobias, which are only needed for media, not for files
Tobiasyes
larmawhich makes it unsuited for file transfer
ralphmlarma: FWIW, I didn't consider XEP-0385 to be limited to photos, videos at all. At VEON we considered it for all kinds of static media, as is mentioned in this XEP's introduction.
Tobiasi don't see how making recommendations for increased interop leads to it being unsuitable to share PDF, ISO, or whatever
ralphmlarma: On top of that, it is useful to define MTI codecs for common media you can show inline.
larmaTobias, because those are SHOULD, which means I as a client SHOULD have a good reason to not implement those codecs
stpeterhas left
larmaThe codecs are there because you do imply a user interface (that displays the media inline, as it says in the title). If I don't want to use this, many things in this XEP become obsolete
ralphmI do have some concerns with this spec though: I'm not convinved about the 'inline' part, and its reliance on References in the way it is currently done. I think I'd rather have References optional and as a sibling. The inline nature is then also optional (for when you refer to a URL to a picture that is then included in the message, much like Twitter's media entities).
larmaThis is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f
ralphmlarma: but you agree that having a list of MTI codecs doesn't prevent /other/ types of media to be transferred as 'other files'?
Tobiasfor me it's kind of obvious that if you don't support inline display at all, the MTI recoomendations don't matter
larmaralphm, I am not saying it does prevent that, it's just that the overall tone of the XEP is "use this to share media that is displayed inline" instead of "use this to share files"
ralphmlarma: I like the example, and think that's how XEP-0385 should work. Optionally with References to mark-up the text in the body.
ralphmlarma: right
nyco-2has joined
Daniel> This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f
+1
Tobiasi imagined that clients either get it via HTTPS or by https://xmpp.org/extensions/xep-0234.html#requesting from some JID
ralphmlarma: note that I had a similar usage in my blog post https://ralphm.net/blog/2019/09/09/fastening
waqashas left
ralphm(scroll down to the image of a mouse)
ralphm(although it is all inside in references, I don't think it has to)✎
ralphm(although it is all inside in references, because it is referring to the previous message, I don't think it has to) ✏
jonas’> This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f
+1, though a mechanism for thunbnails would be good
ralphmjonas’, that example has a thumbnail?
Tobiasjonas’, you could just have a 2nd file-transfer element in there for the hash of the thumbnail
larmajonas’, I was thinking about thumbnails. Best thing I guess would be to use something like ppm in a data uri, but unfortunately most clients probably wouldn't support ppm out of the box and I think it doesn't even have a mime type
jonas’ralphm: right.
jonas’however, having two different syntaxes for mimetype etc is weird
jonas’sibling file elements would make more sense? would also allow for alternative mime types for the same thing (embedded video for example)
larmaI was thinking of additional thumbnail as in blurha.sh-like thumbnails
ralphmUnfortunately SIMS doesn't explicitly point to https://xmpp.org/extensions/xep-0264.html, but it is exactly what Tobias said.
Tobiasjonas’, kind of... but with the idea of SIMIS ( hashes of media/files + metadata + source ) it should be easy to extend it to provide sources for the hash of the thumbnail
larmaaccording to xep-0264, If the URI scheme is 'cid:' then the identifier MUST refer to a bit of binary data as described in Bits of Binary (XEP-0231) [1]
larmaso transport is already defined for 264 thumbnails
ralphmThe nice thing about XEP-0264, I think, is that it builds on Bits of Binary (XEP-0231).
ralphmAnd then have an external storage for the actual, larger, media.
j.rhas joined
larmaThe problem with bob thumbnails is that even those are pretty large for some networks (like mobile when you are throttled to 64kbit/s it can be a significant delay to fetch such image first)
ralphmlarma: if we'd add some kind of identifier to individual <media-sharing/> elements, then you could have a sibling references element to mark up the URL in the body, together with earlier suggestions I made with of having proper child elements in references instead of the current 'type' attribute:
<reference start="0" end="100" xmlns="urn:example:reference:0">
<media id="[the id here]"/>
</reference>
Tobiasmy motivation for 285 was mostly to have a protocol describing what is shared and less so how (because there have been numerous file transfer protocols in the past). Furthermore, by making it content based (via secure hashes) you can easily cache things or have a small reference to the media in MAM where you know in a couple years that this messages includes an image with a certain hash. How you get the image is out of scope for the spec. Clients will likely have a cache of shared media, servers might help here too.
larmaralphm, if we allow content in the body then we can no longer have a fallback body
andyhas joined
ralphmlarma: I looked at your example?
ralphmlarma: my markup just says: that (fallback) body there has a URL in that, that is actually this media object I'm describing next to me, too.
larmaThat seems unnecessary to me, as that's already what it is supposed to be
larmaThat's like adding <i-behave-standards-compliant /> 😀
ralphmlarma: I think it gives us both worlds: 1) a readable plain-text message, 2) a fully marked up thing. Compare how Tweets work: there's plain text representation with a bunch of additional meta data (Tweet Entities and more) that make it possible to show a richer version of it.
ralphmYou then don't "need" a fallback anymore.
larmaI specifically don't want this to be a complex mixed content message, it should just be a file transfer
lorddavidiiihas left
larmaThe fallback in my example will be understood as a file transfer by the majority of clients already, allowing it to be anything else will cause it to no longer be displayed as such
Danielyes. i know what twitter is doing. that certainly has a place. but i also want a method to just share a file
larma^ that
Daniellike we do now with xoob; but with more meta information
ralphmlarma: that's fine. I'm not saying you must, I'm saying you could, when you want to preserve the possibility to do 'inline' media sharing, this is how you could do it.
lorddavidiiihas joined
xsfhas joined
ralphmI.e. adding the <reference/> would be optional, and not needed if you 'just' share a file.
larmaSo that kind of concludes to: I want my proposal to be a new XEP because it does not provide what you call "inline" media sharing
xsfhas left
xsfhas joined
ralphmSo it a) removes the references wrapper, with a way to still optionally do references.
ralphm(b)
larma(I specifically don't want that as it adds a lot of complexity for a completely different usecase that I don't necessarily want to cover)
ralphmAnd my proposal is such that XEP-0385 can be both what Tobias designed, with a slightly altered format, and what you want.
ralphmThe references could be left out entirely, or indeed in the References spec. The only thing you'd need is a way to refer to the media sharing element in case there are more than 1.
waqashas joined
larmaralphm, it's not about what the protocol can do, it's about the question what clients need to do when implementing it. I want to be able to implement file transfer in a compliant way that doesn't require me to support mixed content
ralphmAnd you can.
Wojtekhas joined
ralphmMy proposal is basically: take XEP-0385, remove the wrapping references element, maybe add an id attribute.
ralphm(instead of redoing all of this in a new spec)
ralphmTobias: does that sound right?
larmaSo what do I do if I receive a message like https://gist.github.com/mar-v-in/fff8ff23ef8704229cb3e1dcccf79bfa but don't support mixed media? How do I display it? Just the body or just the file share?
xsfhas left
larmaIn my XEP I would just display the file share because the body should only be a fallback so anything in it is expected to be lost.
larmaIn your XEP I'd need to implement mixed media which can be rather complex in some clients
ralphmThat's a valid point.
calvinhas left
ralphmI guess I assumed you'd always show the body.
ralphmThe thing is, if I go with what you suggest, how do we get to a place where we _do_ want a body with references?
larmaah ok, that might not have been obvious from the XML I shared
larmaralphm, that's why I said that it makes sense to consider this new thing (which I call SFS) something else than SIMS 😉
ralphmlarma: but then how do you "upgrade" from having just SFS, to something with SFS *and* a body with references?
Danieli guess we can just keep sims
Danieland do either sfs or sims
larmait's two different things, there is no straight forward "upgrade" path
Danielit's just two different things
ralphmDaniel, having two specifications that do exactly the same thing with different fallback behaviour seems suboptiomal, though.✎
Danielit's not the same thing
ralphmDaniel, having two specifications that do exactly the same thing with different fallback behaviour seems suboptimal, though. ✏
Danielone is twitter. the other one is file transfer
Daniel(they can probably share their media meta data format wrapper element)
ralphmDaniel: one is sharing media, and having a body that you show, two is sharing media with a body you only show when the media sharing element is not implemented.
krauqhas left
larmatwo is not sharing media, two is sharing a file
ralphma file is a medium, I don't understand the difference.
larmasomething that may be impossible to display inline
adiaholichas left
adiaholichas joined
ralphmI'm not sure if it is that easy to make a clear division. A rich client could show PDFs or other documents "inline". Like Slack does.
Danielin any case i think it is perfectly fine to try both. if during that experiment we realize that there is a lot of overlap we can still merge one into the other
jonas’and ISOs in an inline qemu window
jonas’thanks to qemu.js or how it’s called
ralphmDaniel, oh, let me be clear: I'm a firm believer in accepting proposals as XEPs and then experiment and pick a "winner" later.
ralphmI cannot think of many reasons to *not* accept a specification that lands in the inbox. Other than known or suspected IPR concerns, and whatever formatting requirements Editors set.
larmaOh and by the way, I think we shouldn't use references for that, but use message markup instead 😉
ralphmlarma: we can have a separate discussion on this, but I think message markup and references are the same thing with slightly different flavors.
adiaholichas left
adiaholichas joined
larmaXEP-0372 seems to mix markup with semantic which is very odd to me
stpeterhas joined
larmammh maybe semantic is the wrong word there
ralphmlarma: in my blog post, I altered the syntax, so that there's a <reference/> element with start and end, and then child elements that define the meta data (mention, media, message, link), so that you can do extend it independently.
larmaIt definitely feels wrong to have markup change the routing behavior which is what the mention reference is supposed to do
ralphmwith message markup as I think you suggested, you also have a "thing with start and end" and "meta data about that thing" (emphasise, strike through, etc)
davidhas left
davidhas joined
xsfhas joined
ralphmlarma: wait huh?
ralphmlarma: what does "change the routing behavior" mean?
larmawell, as we discussed on summit we want push notifications based on mentions.
xsfhas left
larmathose are completely distinct concepts to me tbh
ralphmI see mention notifications as a potential server-side side effect
ralphmYou can totally have mentions without notifications. References is primarily about markup.
larmaI don't want server side side effects based on markup, that's my point
larmaAlso what I don't like about XEP-0372 is this "everything is a uri" concept
ralphmThat's ok. References doesn't specify or suggest notifications.
jonas’larma, +1 against the everything is a URI thing
ralphmlarma: did you look at my examples I mentioned two times now?
jonas’re markup with side-effects: markup is inherently semantic.
jonas’or at least, Message Markup (my XEP) is, that’s the whole point
ralphmlarma: I intentionally moved away from the everything-is-a-URI model
ralphmBy having child elements with clear specific semantics
larmayeah, but what is the purpose of the reference thing then? It just seems like a superfluous container element
larmajonas’, Yeah, semantic is the wrong word, I just don't want markup to change how we deliver messages and I felt this was kind of the result of the discussion on summit
jonas’larma, I think it’s the right thing to do
ralphmlarma: my idea was that you have a common thing (start and end attributes) and a specific description of what is to be found there. If you'd like to move the start and end attributes to the 'child' element, you could, but it isn't great for later (independent) extension with other types.
jonas’to make this transparent to the user, it is required that it’s tied to some kind of markup, IMO
calvinhas joined
ralphmjonas’, if you want this to be tied to a specific hint, I'd not be opposed I think.
larmajonas’, but I might want to change notification routing without explicitly mentioning (slack does support that) or mention someone without notifying them (I don't think slack supports *that*)
ralphmlarma: well, you can still mention people in one-on-ones and channels the mentionee isn't in, and then you get asked what to do in the latter case.
jonas’larma, I think the former case is a bad idea
jonas’and the latter case is too
larmajonas’, I want to talk about someone without them being notified, isn't that something rather usual?
jonas’larma, then you don’t @mention them, what’s the problem?
jonas’@mention -> notification
ralphmI'd say in Slack, the thing that causes the notification is not unlike the user configuring keyword mentions for themselves.
xsfhas joined
larmaI want client to correctly reference that person (e.g. display their profile on hover)
ralphm(which is a different way to look at it)
jonas’larma, I suppose a mention-reference could have a silent=true thing in it, which would then also cause appropriate rendering in the recipients client
larmaHow would it be displayed differently?
jonas’but the way it’s presented and the way it’s routed needs to be tied together to avoid confusion and intransparent behaviour
jonas’larma, probably grayed out or something?
ralphmShould it be displayed differently?
jonas’I don’t know the specifics, but it needs to be distinguishable. otherwise, people wonder where their notifications went.
jonas’and then they blame the software because it doesn’t ping them when they’re mentioned
jonas’being pinged when you’re mentioned (unless you turned that off) is pretty much standard and expected
j.rhas left
ralphmjonas’, if I implemented this, receiving side, I'd want all mentions of me to notify me, independently of what the sender suggested.
larmare notify without mentioning, in slack if a message does not cause a user to be notified I can force a notification anyway. It makes sense if I want the message to be delivered in their silent hours even if I don't explicitly mention them
jonas’ralphm, that’s also an option I guess
stpeterhas left
ralphmAnd you can influence the behavior with hints, maybe.
larmajonas’, I think the question how to do it client side (also how the client decides if they want to add the notify=false hint or not) is completely irrelevant for the spec
krauqhas joined
xsfhas left
xsfhas joined
larmaBut I personally would prefer if we just add a <notify jid="that@person.com /> hint to the message instead of having the server parse the markup. That notify also has the positive side effect that it can be used outside the e2ee so servers can actually parse it on e2ee messages
xsfhas left
xsfhas joined
ralphmlarma: but you agree that actual notification is the responsibility of the receiving server then?
larmaralphm, it's always the receiving server to decide, the question is what the server SHOULD base it's decision on
larmaI'd rather do it explicit in the message rather than implicit through specific markup
ralphmWell, you could also take the position that the sending client or server explicitly send a notification.
ralphmI don't like that one, but you could.
ralphmSo I wanted to make it clear.
ralphmI'd be happy with a please-notify-hint.
larmanah I want the sending client to add a hint such that the receiving server (and maybe even client) don't need to parse markup. If they want to do that anyway that's another story
larmaIt just shouldn't be the intended way to parse markup
ralphmTaking into account the use case of "forcing" a notification during dnd. Not sure how to spec that, yet.
ralphmlarma: sounds good to me
nycoSorry for this interruption: Call for help of promotion of the newsletter!
https://fosstodon.org/@xmpp/103606882304524026
https://twitter.com/xmpp/status/1225073484176543747
https://www.linkedin.com/posts/xmpp-standards-foundation_xmpp-jabber-decentralised-activity-6630841055023558656-SFhw/
https://www.reddit.com/r/xmpp/comments/ezb3tg/the_xmpp_newsletter_full_speed_xmpp_universe_04/
https://www.facebook.com/photo.php?fbid=10158047204828454&set=p.10158047204828454&type=1&theater
Like and Share, if you want, what you want, how you want :)
ralphmlarma: a while back you asked about the use of the <reference/> wrapper. Did my explanation make sense?
Wojtekhas left
Wojtekhas joined
xsfhas left
j.rhas joined
larmaralphm, I kind of see the point. But then we would still probably want to merge reference into message markup maybe?
ralphmI'd be happy with a common <markup> wrapper with start/end, and then merge the markup, so you can have <emphasize/> and <mention/> next to each other.
ralphmOr something similar, I'm not sure what's better, start/end on the specific element itself, or on a wrapper, in the face of distributed extensibility. In non-XMPP cases with XML, you'd use namespaced attributes, but I think I don't like that either.
Nekithas left
nyco<emphasize/> also <empathize/> or <ironize/>?
Nekithas joined
stpeterhas joined
ralphmyes
ralphmin your own namespace
waqashas left
pdurbinhas joined
j.rhas left
mukt2has joined
pdurbinhas left
Dele Olajidehas left
Dele Olajidehas joined
mukt2has left
larmahas left
larmahas joined
lovetoxhas joined
alameyohas left
alameyohas joined
vanitasvitaehas left
vanitasvitaehas joined
xsfhas joined
xsfhas left
xsfhas joined
mathijshas left
mathijshas joined
xsfhas left
mathijshas left
mathijshas joined
Danielhas left
Danielhas joined
Yagizahas left
lovetoxhas left
lovetoxhas joined
mathijshas left
mathijshas joined
nyco-2has left
nyco-2has joined
Nekithas left
mathijshas left
mathijshas joined
eevvoorhas left
Steve Killehas joined
nyco-2has left
calvinhas left
calvinhas joined
sonnyhas left
lovetoxhas left
Steve Killehas left
mathijshas left
mathijshas joined
mathijshas left
mathijshas joined
lovetoxhas joined
Steve Killehas joined
pdurbinhas joined
mukt2has joined
j.rhas joined
lovetoxhas left
lovetoxhas joined
lovetoxhas left
pdurbinhas left
sonnyhas joined
lovetoxhas joined
lovetoxhas left
eevvoorhas joined
lovetoxhas joined
mukt2has left
nyco-2has joined
Wojtekhas left
adiaholichas left
adiaholichas joined
Nekithas joined
nyco-2has left
nyco-2has joined
alameyohas left
alameyohas joined
calvinhas left
calvinhas joined
Wojtekhas joined
lovetoxhas left
fippohas left
fippohas joined
fippohas left
fippohas joined
andrey.ghas left
mukt2has joined
andrey.ghas joined
Shellhas joined
adiaholichas left
adiaholichas joined
mukt2has left
mathijshas left
mathijshas joined
calvinhas left
calvinhas joined
moparisthebestanyone see https://snikket.org/ ? pretty neat move
lorddavidiiihas left
lorddavidiiihas joined
moparisthebestwhat is it? messaging platform. how do I chat on it? grab this app. how can I run my own server? run this snikket docker container.
moparisthebestah, figured out who's involved now, nice work!
jonas’:D
jonas’MattJ, ^
moparisthebesthad to track down git repo and commits to figure it out lol, was linked to in jmp.chat muc first
MattJ:)
pep.moparisthebest, #old :p
jonas’pep., never too old for praise
moparisthebestwas it linked in here before? I could have missed it I admit
jonas’also, shaming people for re-sharing "old" news puts an odd incentive against sharing stuff at all
pep.jonas’, can't joke anymore?
pep.I'm not shaming anybody
MattJmoparisthebest: I don't think it was linked here in particular
pep.I haven't seen it here either
MattJI did publish a Prosody blog post yesterday: https://blog.prosody.im/introducing-snikket/
j.rhas left
j.rhas joined
MattJTo be honest the early reaction from XMPP community members wasn't exactly encouraging :)
Wojtekhas left
MattJBut pretty much anyone here is not the target audience
jonas’pep., sorry, I didn’t get the joke part
stpeterso true :-)
Wojtekhas joined
neshtaxmpphas left
moparisthebestif XMPP is weak at one thing, it's marketing, this looks good to me
MattJBut hopefully the blog post gives some background - I've heard a lot of "why another Conversations fork?!"
wojtekhas joined
MattJAnd yes, a bunch of it is simply a layer of marketing :)
moparisthebestreaction in jmp.chat muc which is more users than developers/xmpp community looks promising
stpetermoparisthebest: what's the chatroom for jmp?
MattJYes, had a demo at the XMPP stand at FOSDEM this past weekend and I think it's fair to say it was a success
pep.Everywhere I mentioned it outside of XMPP circles the reaction was good
jonas’moparisthebest, can you hint the admins of that room that their room title isn’t particularly useful (if set at all): https://search.jabber.network/search?q=discuss%40conference.soprani.ca
wojtekhas left
pdurbinhas joined
mukt2has joined
moparisthebestjonas’, thanks, they set one!
Wojtekhas left
Wojtekhas joined
jonas’moparisthebest, :+1:
jonas’(the usual delay of ~1h applies)
mukt2has left
pdurbinhas left
debaclehas left
matkorhas left
matkorhas joined
calvinhas left
Danielhas left
Danielhas joined
lovetoxhas joined
Neustradamushas left
Danielhas left
Danielhas joined
calvinhas joined
ralphmMattJ: I personally think, I hoped to express, that I think the idea and execution so far for Snikket is really good.
ralphmMattJ: I like that you focus on a product rather than the underlying protocol
ralphmMattJ: I'm curious why you think the community wasn't encouraging. What kind of feedback did you get? Everyone I talked to at FOSDEM thought it was great.
ZashSeen a bunch of things like "Why yet another Conversations fork?", "What's the point of this, we already have Prosody?"
MattJNothing serious or surprising - I think it probably didn't click for many people (who weren't at FOSDEM) until I laid it out in the blog post yesterday
MattJPartly my fault, I'd aimed to post that sooner, but got held up by last minute demo preparation
moparisthebest*personally* I see something like that, and the first thing I do is dig to see what the underlying protocol is, software is written in etc etc, I *suspect* I'm not a normal average person in that regard
moparisthebestI see "XMPP" and instantly know all the advantages that provides, that are spelled out there in plain english, again I suspect the normal person does not
MattJRight, I totally get it, it's not a surprising reaction at all for a community of geeks :)
sonnyhas left
sonnyhas joined
MattJWe are used to assessing technology, but there is very little new tech here
fippothe general concern with the trend to package client+server is that it reduces the need for specs (and spec compliance). not a concern in this case i think because of a long record :-)
moparisthebestand to be clear I'm meaning this as praise, to a "normal person" I think that snikket looks a lot better than "grab any XMPP client or server and join in"
ZashGiven the flexibility of XMPP, having clients and servers optimized for each other makes sense.
MattJmoparisthebest: yeah, the FOSDEM reception was great
MattJLots of people new to XMPP had a simple gateway in, that was easily explained as a "self-hostable WhatsApp/Telegram/Signal/..."
mukt2has joined
debaclehas joined
stpeterSnikket: The Gateway Drug to Hardcore XMPP [tm]
MattJTime will tell :)
ralphmstpeter: :-D
stpeterNot the best marketing, I suppose. ;-)
Danielhas left
ralphmMattJ: you should have put the logo in your post
MattJYeah, would have delayed it further though :)
ralphmEh, ok.
MattJCurrently working on docker images that actually work on a Raspberry Pi like we advertised :D