XSF Discussion - 2020-02-05

Zash: free and open flu?

more like: free andn openly distributed epidemic

Yeah, kind of wishing this were a more restrictive licence.

How are you feeling today, dwd ?

Terrible. But nothing that can't be fixed. Doctors coming later this morning.

I hear Guus lost 3 kg, so look on the bright side :/ Hope you feel better soon.

(almost 4, actually)

I hope you feel better soon, Dave.

when did this start? Only after you got back?

my colleague lost purse and smartphone on the way back of FOSDEM. He travelled the whole monday due to lost identity. But he is healthy.

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

pep., 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.

I probably wasn't there when you said that, but ok

I think I mentioned it at the Summit, too, but no worries.

That's something we say every year, in quite some abundance.

Most of them were from the Matrix people.

intosi, not all of us have been involved for the same amount of time

Also that's a FOSDEM-specific thing, because I've been running other conferences and it usually works well that way :)

Having 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.

(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)

https://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?

(as the retraction message has no body, that message might not be archived by MAM implementations that are not aware of XEP-0424)

Maybe adding a store hint to the XEP would help?

but aren't hints deprecated?

flow, it's deferred

but it was very much disliked by the Council that decided on it last time

There is no replacement for it other than fallback bodies which is stupid for things like retraction really

larma: fwiw, so is MAM itself (deferred) :-D

there 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

what 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

larma: 334 contains the exhaustive list of hints. If you add a new hint, you need to version-bump Hints

and if you don't version-bump, you can't have hints with new semantics that require special processing

why?

or just make another XEP with whatever other hints

"Hints 4, this time it's serious"?

MattJ, same issue?

What issue?

The whole point is btw that they are "hints", it's meant to not be a disaster if they aren't followed

Not saying I understand what Ge0rG is saying, but bumping a XEP or creating a new one is technically equivalent in general

They are also meant to be semantic, rather than tied to specific protocols

pep.: 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

So no-copy is not tied to Carbons, but any copying-to-other-resources mechanism

Ge0rG, even better!? :p

Usually 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

pep.: so why not have each hint in the XEP that contains the actual processing semantics that are affected by the hint?

larma: Carbons do have their own "hint"

Ge0rG, sure. It's not what I was replying to

but I think that Carbons and MAM are actually good causes to fix message routing and persistence semantics, i.e. IM 2.0

We started this discussion about store hint 😉

msg to bare --> persistent, copy-everywhere message to full --> ephemeral, no Carbon, no MAM, no offline store

We 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.

> 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.

Ge0rG, 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)

Guus, how do you want to show retractions to clients that don't support it?

"The message you're still seeing above -- because I don't support retraction -- has been retracted" ?

pep. basically. I'd include a copy of the retracted body, prefixed with 'retracted' or something.

it can be ugly

that, if anything, motivates client developers to add support. 🙂

It is to me, and also useless

larma: 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.

Guus, you'd be helping the spammer to spam :P

Guus: that's a nice reminder to screenshot the messages!

Definitely not useless. A client that receives a retraction, but does not support _or_ show it through a fallback, is dangerous.

both chat participants will have a very different understanding of the correspondence state.

Guus, how is it dangerous

I think we get into social territory, and I'd rather not

If 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.

Ge0rG, 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?

Guus, I could say the same of every single feature that's socially used in context.

I still use presence information and talk about it sometimes, should I put that as fallback body somewhere?

no, this is not a social thing

this is a semantic thing

larma: what if we want to use longterm to not do stupid things now?

you, as a receiver, missed the fact that I, as the sender, changed the semantics.

You removed a spam message for convenience. It's fine if I still see it.

spam, sure

Or you removed information that I wasn't supposed to see, well too bad.

why would I delete my own spam, btw?

Not your own

also true of any "styling" XEPs right? changed meaning and all that

you can only retract your own messages with that XEP, afaik.

Ah ok I had moderation in mind, similar case

Ge0rG, 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?

The 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.

that really has very nasty real-world problems.

deprecation before replacement sounds like a stupid concept for me

If will lead to situations where people do not _trust_ the messages they receive from XMPP.

and that is killing.

larma: I told you the reasons I remember for Council not advancing hints.

I don't really agree with this assessment

pep. suffer from it once, and you will. Trust me on that one.

[citation required]

Ge0rG, 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)

- I don't like XXX - Oops that wasn't for you - retracted: I don't like XXX

:P

larma: regarding Hints, I even do agree with the argumentation

pep. now imagine that you didn't type "- Oops that wasn't for you"

Guus, so you see twice "I don't like XXX" in clients that don'T support it?

(why would you type that, if you expect the receiving entity to receive the retraction)

Very much fixing the issue

You see: - I dont like XXX - RETRACTED: I dont like XXX which is ugly as hell, but at least has the correct, intended, semantic value.

How does that help with anything

Now you've seen twice that XXX (potentially YOU), I don't like.

For clients that do not support the XEP, the message has been displayed at least once anyways, so there's little additional harm.

For clients that do support it the message may be removed, so the fallback is useless

If you don't include the fallback message in the retraction, the receiving entity might be completely unaware that the message is retracted.

Those would only see: - I don't like XXX

(no retraction)

Guus, same as if the retraction message got lost 😉

legacy clients might not be doing MAM

yes, 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'.

this is not a MAM issue.

the fact that it also makes it more likely that existing MAM implementations might behave a bit better is a nice side-effect. ✏

if my legacy client does not do mam/carbons it is likely to happen that this client does not receive the retraction message at all

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

let's call my legacy client pidgin, which apparently is the most popular XMPP client

It's like we're trying to write protocols on top of XMPP's <body/>

we 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.

pep. I'm very much with you that this is ugly.

but I think it is necessary.

I don't

a situation in which a message was retracted by the sender, without the recipient being aware of it, must be avoided.

Guus, 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

larma: 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).

we must have a decent fallback.

that's why it's called just that, a fallback.

Guus, we already broke Pidgin effectively

Also these fallback things force any implementation to support things they wouldn't want to support

They don't force you to do anything

In a way yes. Now you're sending me that ugly RETRACTED: foo

Or > foo\n<reaction>, or.. some other fallback

I 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.

That's simply dangerous

ideally, 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?

Yes the "send everything to all clients because MAM/carbons" argument

I need to get back to work.

(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?

larma, i'd present the "new" xep the community and potentially council and see if there is a clear opinion on that

also maybe reach out to Tobias the xep385 author

larma, what kind of issues?

Tobias, - 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)

larma, 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.

underspecified URIs?

you mean these https://tools.ietf.org/html/rfc6920 ?

It 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

I 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

(my proposal changes it to use the jinglepub element defined in XEP-0385 which allows providing a jingle description element)

protocol 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.

defined in 385 or 358?

358, sorry

ah..ok

I 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

the SHOULDs are there for interoperability in user interface

Tobias, which are only needed for media, not for files

yes

which makes it unsuited for file transfer

larma: 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.

i don't see how making recommendations for increased interop leads to it being unsuitable to share PDF, ISO, or whatever

larma: On top of that, it is useful to define MTI codecs for common media you can show inline.

Tobias, because those are SHOULD, which means I as a client SHOULD have a good reason to not implement those codecs

The 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

I 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).

This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f

larma: but you agree that having a list of MTI codecs doesn't prevent /other/ types of media to be transferred as 'other files'?

for me it's kind of obvious that if you don't support inline display at all, the MTI recoomendations don't matter

ralphm, 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"

larma: I like the example, and think that's how XEP-0385 should work. Optionally with References to mark-up the text in the body.

larma: right

> This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f +1

i imagined that clients either get it via HTTPS or by https://xmpp.org/extensions/xep-0234.html#requesting from some JID

larma: note that I had a similar usage in my blog post https://ralphm.net/blog/2019/09/09/fastening

(scroll down to the image of a mouse)

(although it is all inside in references, because it is referring to the previous message, I don't think it has to) ✏

> 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

jonas’, that example has a thumbnail?

jonas’, you could just have a 2nd file-transfer element in there for the hash of the thumbnail

jonas’, 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

ralphm: right.

however, having two different syntaxes for mimetype etc is weird

sibling file elements would make more sense? would also allow for alternative mime types for the same thing (embedded video for example)

I was thinking of additional thumbnail as in blurha.sh-like thumbnails

Unfortunately SIMS doesn't explicitly point to https://xmpp.org/extensions/xep-0264.html, but it is exactly what Tobias said.

jonas’, 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

according 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]

so transport is already defined for 264 thumbnails

The nice thing about XEP-0264, I think, is that it builds on Bits of Binary (XEP-0231).

And then have an external storage for the actual, larger, media.

The 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)

larma: 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>

my 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.

ralphm, if we allow content in the body then we can no longer have a fallback body

larma: I looked at your example?

larma: 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.

That seems unnecessary to me, as that's already what it is supposed to be

That's like adding <i-behave-standards-compliant /> 😀

larma: 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.

You then don't "need" a fallback anymore.

I specifically don't want this to be a complex mixed content message, it should just be a file transfer

The 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

yes. i know what twitter is doing. that certainly has a place. but i also want a method to just share a file

^ that

like we do now with xoob; but with more meta information

larma: 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.

I.e. adding the <reference/> would be optional, and not needed if you 'just' share a file.

So 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

So it a) removes the references wrapper, with a way to still optionally do references.

(b)

(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)

And my proposal is such that XEP-0385 can be both what Tobias designed, with a slightly altered format, and what you want.

The 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.

ralphm, 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

And you can.

My proposal is basically: take XEP-0385, remove the wrapping references element, maybe add an id attribute.

(instead of redoing all of this in a new spec)

Tobias: does that sound right?

So 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?

In 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.

In your XEP I'd need to implement mixed media which can be rather complex in some clients

That's a valid point.

I guess I assumed you'd always show the body.

The thing is, if I go with what you suggest, how do we get to a place where we _do_ want a body with references?

ah ok, that might not have been obvious from the XML I shared

ralphm, that's why I said that it makes sense to consider this new thing (which I call SFS) something else than SIMS 😉

larma: but then how do you "upgrade" from having just SFS, to something with SFS *and* a body with references?

i guess we can just keep sims

and do either sfs or sims

it's two different things, there is no straight forward "upgrade" path

it's just two different things

it's not the same thing

Daniel, having two specifications that do exactly the same thing with different fallback behaviour seems suboptimal, though. ✏

one is twitter. the other one is file transfer

(they can probably share their media meta data format wrapper element)

Daniel: 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.

two is not sharing media, two is sharing a file

a file is a medium, I don't understand the difference.

something that may be impossible to display inline

I'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.

in 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

and ISOs in an inline qemu window

thanks to qemu.js or how it’s called

Daniel, oh, let me be clear: I'm a firm believer in accepting proposals as XEPs and then experiment and pick a "winner" later.

I 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.

Oh and by the way, I think we shouldn't use references for that, but use message markup instead 😉

larma: we can have a separate discussion on this, but I think message markup and references are the same thing with slightly different flavors.

XEP-0372 seems to mix markup with semantic which is very odd to me

mmh maybe semantic is the wrong word there

larma: 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.

It definitely feels wrong to have markup change the routing behavior which is what the mention reference is supposed to do

with 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)

larma: wait huh?

larma: what does "change the routing behavior" mean?

well, as we discussed on summit we want push notifications based on mentions.

those are completely distinct concepts to me tbh

I see mention notifications as a potential server-side side effect

You can totally have mentions without notifications. References is primarily about markup.

I don't want server side side effects based on markup, that's my point

Also what I don't like about XEP-0372 is this "everything is a uri" concept

That's ok. References doesn't specify or suggest notifications.

larma, +1 against the everything is a URI thing

larma: did you look at my examples I mentioned two times now?

see also: https://mail.jabber.org/pipermail/standards/2018-March/034559.html

ralphm, I did

re markup with side-effects: markup is inherently semantic.

or at least, Message Markup (my XEP) is, that’s the whole point

larma: I intentionally moved away from the everything-is-a-URI model

By having child elements with clear specific semantics

yeah, but what is the purpose of the reference thing then? It just seems like a superfluous container element

jonas’, 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

larma, I think it’s the right thing to do

larma: 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.

mentions influence notification routing inherently

to make this transparent to the user, it is required that it’s tied to some kind of markup, IMO

jonas’, if you want this to be tied to a specific hint, I'd not be opposed I think.

jonas’, 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*)

larma: 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.

larma, I think the former case is a bad idea

and the latter case is too

jonas’, I want to talk about someone without them being notified, isn't that something rather usual?

larma, then you don’t @mention them, what’s the problem?

@mention -> notification

I'd say in Slack, the thing that causes the notification is not unlike the user configuring keyword mentions for themselves.

I want client to correctly reference that person (e.g. display their profile on hover)

(which is a different way to look at it)

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

How would it be displayed differently?

but the way it’s presented and the way it’s routed needs to be tied together to avoid confusion and intransparent behaviour

larma, probably grayed out or something?

Should it be displayed differently?

I don’t know the specifics, but it needs to be distinguishable. otherwise, people wonder where their notifications went.

and then they blame the software because it doesn’t ping them when they’re mentioned

being pinged when you’re mentioned (unless you turned that off) is pretty much standard and expected

jonas’, if I implemented this, receiving side, I'd want all mentions of me to notify me, independently of what the sender suggested.

re 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

ralphm, that’s also an option I guess

And you can influence the behavior with hints, maybe.

jonas’, 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

But 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

larma: but you agree that actual notification is the responsibility of the receiving server then?

ralphm, it's always the receiving server to decide, the question is what the server SHOULD base it's decision on

I'd rather do it explicit in the message rather than implicit through specific markup

Well, you could also take the position that the sending client or server explicitly send a notification.

I don't like that one, but you could.

So I wanted to make it clear.

I'd be happy with a please-notify-hint.

nah 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

It just shouldn't be the intended way to parse markup

Taking into account the use case of "forcing" a notification during dnd. Not sure how to spec that, yet.

larma: sounds good to me

Sorry 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 :)

larma: a while back you asked about the use of the <reference/> wrapper. Did my explanation make sense?

ralphm, I kind of see the point. But then we would still probably want to merge reference into message markup maybe?

I'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.

Or 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.

<emphasize/> also <empathize/> or <ironize/>?

yes

in your own namespace

anyone see https://snikket.org/ ? pretty neat move

what 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.

ah, figured out who's involved now, nice work!

:D

MattJ, ^

had to track down git repo and commits to figure it out lol, was linked to in jmp.chat muc first

:)

moparisthebest, #old :p

pep., never too old for praise

was it linked in here before? I could have missed it I admit

also, shaming people for re-sharing "old" news puts an odd incentive against sharing stuff at all

jonas’, can't joke anymore?

I'm not shaming anybody

moparisthebest: I don't think it was linked here in particular

I haven't seen it here either

I did publish a Prosody blog post yesterday: https://blog.prosody.im/introducing-snikket/

To be honest the early reaction from XMPP community members wasn't exactly encouraging :)

But pretty much anyone here is not the target audience

pep., sorry, I didn’t get the joke part

so true :-)

if XMPP is weak at one thing, it's marketing, this looks good to me

But hopefully the blog post gives some background - I've heard a lot of "why another Conversations fork?!"

And yes, a bunch of it is simply a layer of marketing :)

reaction in jmp.chat muc which is more users than developers/xmpp community looks promising

moparisthebest: what's the chatroom for jmp?

Yes, had a demo at the XMPP stand at FOSDEM this past weekend and I think it's fair to say it was a success

Everywhere I mentioned it outside of XMPP circles the reaction was good

stpeter, xmpp:discuss@conference.soprani.ca?join

thanks!

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

jonas’, thanks, they set one!

moparisthebest, :+1:

(the usual delay of ~1h applies)

MattJ: I personally think, I hoped to express, that I think the idea and execution so far for Snikket is really good.

MattJ: I like that you focus on a product rather than the underlying protocol

MattJ: 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.

Seen a bunch of things like "Why yet another Conversations fork?", "What's the point of this, we already have Prosody?"

Nothing 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

Partly my fault, I'd aimed to post that sooner, but got held up by last minute demo preparation

*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

I 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

Right, I totally get it, it's not a surprising reaction at all for a community of geeks :)

We are used to assessing technology, but there is very little new tech here

the 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 :-)

and 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"

Given the flexibility of XMPP, having clients and servers optimized for each other makes sense.

moparisthebest: yeah, the FOSDEM reception was great

Lots of people new to XMPP had a simple gateway in, that was easily explained as a "self-hostable WhatsApp/Telegram/Signal/..."

Snikket: The Gateway Drug to Hardcore XMPP [tm]

Time will tell :)

stpeter: :-D

Not the best marketing, I suppose. ;-)

MattJ: you should have put the logo in your post

Yeah, would have delayed it further though :)

Eh, ok.

Currently working on docker images that actually work on a Raspberry Pi like we advertised :D

(current ones are x86 only)

Drug dealers often lie, so there's that.