So, starting off a topic that might be even worse than banning someone: Why is the discussion about omemo completely silent? I remember a few weeks (months?) ago someone wrote a mail asking about a technical change in the protocol to move from a signal-only technique to some wide-spread alternative and I was really hyped to contribute to this discussion but then nobody replied and the thread just died.
So what's the thing about omemo? Why is there no heated discussion? I see two pull requests in the xsf repo just gathering dust.
Syndace
Oh I should add I have'nt read the chats in about two weeks, I may have missed something recently.
Flow
What Holger said. Besides Zinids choice of words, I did not notice him insulting someone.
Flow
Syndace, I guess there current OMEMO implementations are happy with they way they are
Flow
*the current
Flow
At least I have no incentive to work on an OMEMO-NEXT which just changes a crypto primitive for another one, when I think the current primitive is perfectly fine for all use cases.
Archas left
Steve Kille
I thought that Ralph made a good call here
Syndace
Huh, that answer is not satisfying. The current stadard just tells people to use lib signal without having any actual alternative or even knowing the insides of the protocol. I thought the goal was to move away from libsignal asap, as it is GPL3'd and not maintained by us. If we ever decide to change something about omemo that does not comply to the way lib signal currently works we have a lot of trouble.
Flow
Steve Kille, I think the ban was at least borderline. Asking someone to be polite, sure. But otherwhise people could just "/ignore Zinid"
ralphm
I don't understand. There's a difference between a protocol and a library in terms of licensing.
ralphm
Flow: FWIW, I already lifted the ban
Flow
Syndace, That is why we had Andy's PR which was an attempt to move away from "protobufs as libsignal does them" towards "those are the fields and this is how we put them into XML"
ralphm
If he keeps it up, though, I'll waste not so many words as yesterday.
Flow
ralphm, yeah, there is a difference between a protocol and a library in terms of license, but the fact that all libsignal impls are GPL'ed was brought up again and again
Flow
it was especially XEdDSA which is part of libsignal
ralphm
Sure. So either someone does a clean room implementation with a different license, or something new happens. This is nothing new?
Flow
IIRC
Flow
ralphm, yeah, but why make something new if XEdDSA is an open specification
ralphm
We've marked specifications as 'historical' instead of 'standard' before for reasons like that.
ralphm
Flow: I agree. But then the only obstacle is, well, doing something?
Flow
ralphm, I'm sorry, only had my first cup of coffee, I can't follow
Syndace
Flow, not something new but something that is included in 90% of all crypto-libraried you can find in the wil
Syndace
wild*
Syndace
instead of something that does the same and has just one single implementation out there
Flow
Syndace, there are multiple
ralphm
Flow: my point is that a library license is not necessarily interesting for defining a protocol. It might be for adoption, though. If someone cares enough, that problem goes away. If people just keep complaining instead, it doesn't.
Flow
ralphm, I think you are saying what I've been saying the whole time
ralphm
I happy to be in violent agreement.
ralphm
I'm
Syndace
Flow, are you sure it's not all just ports of the singal implementation? I'm having a hard time finding another one on google.
Flow
But unfortunately, the unwritten (?) "there can only be once experimental XEP for $foo" philosophy has stopped the effort to standardize OMEMO based on the open signal specifications
Flow
Syndace, it's still multiple implementations, no?
daniel
Syndace: do you have stakes in this? Do you maintain a client or something? If so implement something, spec something and propose this
daniel
In my experience change does come from discussing things to dead but from implementing and specing it out
daniel
*doesn't
Flow
"change does come from discussing things", hehe if that where true we had a long of change in XMPP-land ;)
Flow
yeah, but daniel is essentialy right, to many specs, and that includes MIX, make to much spec progress without an accompaning impl
daniel
*cough* OK
daniel
OX
daniel
Dann it i can't type. I need coffee
ralphm
Flow: I don't recall such a policy. We've had multiple competing experimentals at a time before.
Flow
daniel, hmm, well but I think the basics of OX are far less complex than e.g. MIX or OMEMO
Syndace
daniel, agreed, altough one of the pr's already includes the change I'm proposing.
So what do you all think:
If I publish a library which does omemo encryption without xeddsa first and THEN try to start the discussion again, will it change things and be more likely to actually move away from libsignal?
Flow
and there are at least two prototypcial impls I'm aware of
ralphm
in fact most of the current building blocks have had multiple different proposals. Disco (Browse, Agents), PubSub, Jingle (SI).
Flow
but yes, more OX impls for the greater good!
ralphm
Usually the driving force should be _running code_
Flow
ralphm, then we can continue working on what Andy proposed?
ralphm
I don't think anyone can (or would want to) block working on competing standards.
ralphm
For interop, though, eventually, one should prevail.
Flow
Cool, then we could also start work on a MIX competitor
daniel
> daniel, hmm, well but I think the basics of OX are far less complex than e.g. MIX or OMEMO
Sure. I just meant to say it's not implemented
Flowhands daniel a virtual cop of coffee while he gets a physical one for himself
Kevhas left
ralphm
You wouldn't be the first. The Erlang Solutions people have worked on MUC Light. I personally think that MIX is the way to go to eventually.
ralphm
MIX is of course comprehensive and there are a lot of moving parts before getting there.
ralphm
Making more focused protocols is always easier.
Flow
ralphm, yep, the MUC light situation come to my mind too. And I agree that ideally everyone would be working on the same thing. But for such a crucial building block as persisent groupchat, I wouldn't want to bet all my money on a single horse
ralphm
The thing I like about MIX most are a) relating occupants on bare JIDs, b) persistent occupancy, even if not online, c) extensible orthogonal streams
daniel
Flow, i'm personally came to believe that forward secrecy is totally unnecessary and kills UX and I would prefer something like OX actually. but I don't want to be the single driving force for something like this again. plus I lot of the change i'm trying to push with OMEMO (like proper access control on pubsub) will benefit OX as well.
ralphm
My pet peeve about, for example, Slack, is integrations messing up conversation in the same channel. With MIX an integration would be on a separate node, and a client can make choices on how to represent such streams in a different way.
Flow
daniel, good to hear that you would probably be interessted in OX for Conversations. I plan to do a OX sprint around march next year (our research project has an evaluation in january, so most people are panicing and there is a lots of stuff to do until then)
Flow
daniel, lovetux also wanted to improve they way keys are announced and stored
daniel
in OX?
Flow
yep
daniel
with a meta note?
Flow
so waiting after that has been spec'ed may be a good idea
Flow
yep
danielhas left
Flow
(given we talk about the same meta node approach)
daniel
the real issue by the way is that we have to retrieve all pep notifications again and again on every login (instead of them landing in MAM for example) - meta or not that a lot of traffic
Flow
daniel, you can configure PubSub nodes to not do that
daniel
a login on my personal device with tens of people having avatars and omemo is really really expensive these days
Flow
(see my discussion in here with lovetux a few days ago)
daniel
Flow, will they be sent instead (and sent to mam) even if i'm offline?
daniel
because just not receiving updates at all doesn't solve the situation
ralphm
PEP is just a profile of PubSub with very specific use cases. If you want other behaviour for nodes-on-user-accounts, that's totally fine.
ralphm
And of course they can integrate just fine with MAM
daniel
ralphm, a) i know b) tell that to the prosody developers :)
ralphm
MattJ: ^
ralphm
:D
Flow
daniel, you want to search xep60 for pubsub#send_last_published_ite
Flow
m
Flow
daniel, I think so
Flow
(not sure about MAM, probably depends on the MAM service impl)
jubalhhas joined
daniel
in any case; making pep a proper pubsub child (in the implementations) and being able to configure something like access control and send_last_published_item and also storing them in MAM is some good preperation that OX, OMEMO and OMEMO-NEXT can all benefit from
daniel
thus far we haven't even managed to make publish_options work on all servers
daniel
at least we are getting there with ejabberd now
Flow
daniel, right but thats a spec vs impl thing
Flow
the only thing we can do from the spec side is to ensure that the required baseline profile is as minimalistic as possible
Flow
(looking at you MIX)
Flow
and that baseline should be ideally able to fullfil >85% of the use cases
daniel
Flow, yes sure. but I like to implement things in Conversations that will actually work so I need server side implementations
daniel
besides having access control would allow us to move bookmarks into pep and get other clients notified if one client changes things. imagine how great that would be if we could sync bookmarks across multiple devices in the year 2018
Flow
daniel, absolutely comprehensible
Guushas left
Flowjust noticed that at next Summit/FOSDEM, drumpf will be president for >1 y
jubalhhas left
xnyhpshas joined
Guushas left
marchas joined
danielhas left
ralphmhas left
lumihas joined
zinid
> I think the ban was at least borderline
you cannot ban anyone in XMPP :)
zinid
and ignoring is not implemented, so, deal with it ;)
Holgerhas left
Flow
zinid, peozio supports /ignore (although I've never used it, and don't plan to do so)
archas left
archas joined
danielhas left
zinid
Flow: nice
danielhas left
la|r|mahas joined
Alexhas joined
lskdjfhas joined
Guushas left
Guushas left
ralphmhas joined
danielhas left
fippo
is there a new presence subscription spam wave?
ralphm
I did get a bunch over last week
Ge0rG
fippo: ongoing right now
Alex
fippo: yes, denied already 20 subscriptions today
fippo
word + three digits as username... now sure if there is a pattern in the resource but i would not expect any
fippo
fun :-/
Alex
yes, same pattern here
danielhas left
Steve Killehas left
Guus
I appear to be on a different list then
danielhas left
blablahas joined
jerehas joined
blablahas left
ralphmhas joined
Tobiashas left
danielhas left
goffihas left
ralphmhas joined
MattJ
Ge0rG, master of all things XMPP 2.0, should headline/normal messages be archived?
Zashhas joined
goffihas joined
jabberatdemohas joined
Ge0rG
MattJ: yes/no in my current opinion, but this is subject to other factors I haven't thought through yet
MattJ
Oh really
MattJ
I'd have thought yes/no if both would be different
MattJ
headline is defined as transient, no offline storage, etc.
MattJ
*no/yes
Ge0rG
MattJ: right, no/yes
MattJ
...
MattJ
Ok, we both made the same typo, that's ok then :)
Ge0rG
MattJ: but it would make sense to decouple persistence from type
daniel
wouldn't the full jid / bare jid approach work as well?
Ge0rG
daniel: yes, it's my preferred approach
MattJ
Mine too
jonasw
Ge0rG, I heard you on council now ;-)
MattJ
But until we can find a sensible transition path to full/bare, I'm sadly living in reality
Ge0rG
I've also updated my slide deck with the rfc routing rules, as those are complex enough already
daniel
MattJ, if that's about 0313 i wouldn't touch the rules regarding headline
daniel
for now at least
jonasw
could we change 0313 to the full/bare thing sensibly after it moving to draft?
jonasw
it is based on message types currently, I think that could be considered as a breaking change
Ge0rG
MattJ: can we change the MAM response message type to headline please?
MattJ
But the MAM responses are sent to the full JID :)
Ge0rG
Yes
MattJ
jonasw, don't worry, I'm not planning on coding any rules into XEP-0313 (which is currently intentionally very light on rules)
jabberatdemohas left
MattJ
other than I think we all agree that groupchat shouldn't be archived
Ge0rG
But there are servers in the reality you just mentioned that will reroute full JID normal messages
MattJ
which are those?
Guushas left
MattJ
because I thought that was in the spec
Ge0rG
MattJ: ejabberd, because it broke message delivery for Gajim users
MattJ
6120 says: "If the JID contained in the 'to' attribute is of the form <localpart@domainpart/resourcepart> and the user exists but there is no connected resource that exactly matches the full JID, the stanza SHOULD be processed as if the JID were of the form <localpart@domainpart>"
Ge0rG
I'm sure we are going to experience funny effects with MAM MUC queries on ejabberd
Ge0rG
Ge0rG [21:49]:
> So I've updated the "XMPP broken" presentation slides, including a screenshot. https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf
MattJ: ^
MattJ
Ok, this section is more detailed: https://xmpp.org/rfcs/rfc6121.html#rules-localpart-fulljid
Ge0rG
There is a table of the relevant cases
MattJ
What's the case for MAM results having type="headline"?
Ge0rG
MattJ: the ejabberd inconsistency and also that headline messages are ephemeral
MattJ
I'm not updating the spec for an implementation bug
MattJ
and I agree that in hindsight, headline has cleaner semantics for these messages, but is it worth another namespace bump?
daniel
MattJ, are you going to accept my PR so jonasw can merge it before we are getting caught up in trying to fix $everything?
MattJ
daniel, yes, sure
jonasw
s/jonasw/$editor/
daniel
MattJ, Ge0rG maybe put the headline thing on a todo in case we will do another ns bump anyway for some other reason
MattJ
FWIW I started this conversation with an innocent question that is not at all related to updating XEP-0313
jonasw
what about todo lists in XML comments in the xep files themselves?
MattJ
I'm working on code at the moment
MattJ
jonasw, that happens to be what I do locally :)
jonasw
:)
daniel
regarding the headline thing; I would like to have a situation where pep publish notifitcation messages can go to mam but the resend on login messages don't
Guushas left
daniel
i'm not sure if they are addressed to bare-jid / full-jid respectively
Ge0rG
MattJ, daniel: I'm not sure we really need a namespace bump for the type change. Most client implementations don't care about it anyway
zinidhas left
MattJ
Most? What about the ones that do? :)
Ge0rG
MattJ: those haven't implemented MAM anyway yet? 😁
Ge0rG
Okay, I have no idea which clients explicitly filter on message type.
Alexhas left
xramhas joined
Ge0rG
And you really don't want MAM responses to end up in offline storage, do you?
MattJ
No, but as I understand it, that will only happen on ejabberd due to a bug
MattJ
and even then, it's not the end of the world
MattJ
If the client uses queryid, it won't get confused, and will just ignore them
Ge0rG
MattJ: a server implementation can store incoming normal messages to offline as well
MattJ
That's not what your table says
MattJ
6121: "For a message stanza of type "normal", "groupchat", or "headline", the server MUST either (a) silently ignore the stanza or (b) return an error stanza to the sender, which SHOULD be <service-unavailable/>. "
daniel
> regarding the headline thing; I would like to have a situation where pep publish notifitcation messages can go to mam but the resend on login messages don't
maybe that's more of an argument to make pubsub publish messages type=normal
maybe headline should never be stored anywhere. else we will loose the difference between normal and headline
Ge0rG
MattJ: what does prosody do?
Ge0rG
MattJ: oh, you are right
Ge0rG
I think we need a new message type 'system'...
MattJ
Ge0rG, let's not talk about Prosody :)
MattJ
(looks like it treats chat/normal the same here)
Ge0rG
Though I must admit it probably won't happen in this universe
MattJ
and in my head, they were equivalent, and only headline was not stored
Ge0rG
MattJ: I'm already glad I took the time to make this table
MattJ
But it's a trivial fix
MattJ
Me too
Ge0rG
MattJ: it will break users' expectations
MattJ
No, because no users use type=normal :)
nycohas left
MattJ
and if they do, they have expectations of it breaking
Ge0rG
MattJ: you can ask Holger, he fixed it as well, and had to revert almost immediately
Ge0rG
MattJ: users have no idea about message type
Ge0rG
MattJ: all they care about is that suddenly prosody broke message delivery
MattJ
What clients other that Gajim and Psi allow you to send type=normal?
MattJ
*than
nycohas joined
Ge0rG
MattJ: I have no idea
goffi
SàT allows it and use normal messages
MattJ
So three clients so far. How many of those will send type=normal to the full JID?
goffi
(haven't read the whole log, just the last few lines, so I'm not sure what this is about)
MattJ
goffi, the spec says that type=normal to a full JID should not be stored as an offline message
MattJ
if the resource is offline
goffi
it's technically possible to send to full jid from SàT using command line, but I don't think there is a reason why a user would do that.
Ge0rG
MattJ: gajim was accidentally sending normal to full JID.
goffi
but I though only headline message were not stored offline?
goffi
thought*
MattJ
goffi, "I don't think there is a reason why a user would do that" - https://xkcd.com/1172/
MattJ
goffi, I thought that too (and Prosody does that)
MattJ
But seems we were all wrong
MattJ
Ge0rG, ok, surely that must be in the case that the recipient is online?
MattJ
Ge0rG, don't tell me it sends to a full JID when they are offline
MattJ
-> I'm curious what Holger fixed, and how it was noticed so quickly
goffi
MattJ: forgot this one :D
goffi
for the record there is an experimental plugin in SàT which allows to send and read messages through an email client (MUA), and this is case message of type "normal" can be filtered to be only readable from email client.
Ge0rG
MattJ: it doesn't matter whether the user is offline at the time of sending because RACE CONDITIONS!!!1!
MattJ
Ge0rG, yes, but this race condition wouldn't happen that often
Ge0rG
MattJ: please ask Holger for the details, and maybe also lovetox
Ge0rG
MattJ: I know Holger linked to the revert commit in here, some weeks ago, but I'm on my mobile now, and haven't implemented search yet
MattJ
ok
Flow
why is it so important what MAM services store, isn't it more important what they return on a query?
MattJ
They can't return stuff they don't store
MattJ
and there is a cost to storing *everything*
Flow
I can see that groupchat messages should not be returned on normal client catch-up, but does that automatically mean xep313 must forbid services storing them?
MattJ
Given that nowadays we're into replicating everything to every client, the optimal path is that everything we want on every client is what is stored
MattJ
and what we don't want on every client is not stored
Alexhas joined
Flow
MattJ, of course there is a cost, but I want total freedom for MAM services regarding what to store
MattJ
Then what you're asking is for the MAM service to be able to store stuff that is "hidden" from a default query
zinidhas joined
MattJ
I think that would be fine
Ge0rG
Flow: that's exactly what I wrote to the ML yesterday
Flow
MattJ, not strictly, but yes
Flow
I believe the construction site should be the MAM query mechanism, not the archiving rules
Flow
Although I also don't like the current MAM version to require services to store groupchat messages
Ge0rG
I'm not sure if the wording in the XEP speaks about what's stored or what's returned, but there's some room for a xep that stores more and provides an extension to query for that
Ge0rG
Unless we can make MUC work on an account, kind of like MIX light, there is no way for account local MUC archives
MattJ
Flow, the current version doesn't require that
MattJ
Oh wait, it does
Flow
MattJ, A server SHOULD also include messages of type 'groupchat' that have a <body>
MattJ
Yeah, sorry, that's what we discussed on the list
MattJ
I'm still surprised at that text :)
Flow
MattJ, no worries, $stuff's complicated
MattJ
Daniel made a PR to fix it anyway
MattJ
so it'll be gone soon
Flow
MattJ, IIRC Daniel PR no requires MAM services to not store groupchat messages
Flow
which is also not good IMHO
MattJ
Heh
Flow
*now
Flow
But you should now best, because you just approved it ;)
Flow
*know
MattJ
I think what you want is sensible, but shouldn't be part of the default query
Flow
A server SHOULD NOT include messages of type 'groupchat' in a user archive
MattJ
so in a sense the spec should separate the idea of storing something, from returning it in a query
Flow
MattJ, exactly
MattJ
I'm totally fine with that, just figuring out how to cleanly word that will be tricky
Ge0rG
MattJ: yes please
MattJ
PRs welcome
MattJ
I'm currently working on restructuring Prosody's message delivery code to make XMPP 2.0 stuff easier (this is the ongoing side project that includes the rewrite of mod_smacks)
MattJ
I'm fed up of missing messages from my wife because my phone battery was flat, and they got "successfully delivered" to poezio, which is online 24/7
marc
What's XMPP 2.0?
MattJ
Pretend I said something else
Ge0rG
MattJ: and this is why I'm using a separate account for my family communication for many years already
jonasw
marc, "Message Routing 2.0" is probably a more accurate term
jonasw
marc, there are a few issues with how XMPP message routing behaves with multiple clients online on the same account at different or the same times
MattJ
jonasw, but what a mouthful. We need a marketing term :)
jonasw
MattJ, sure, but we don’t need to market to marc, I think :)
marc
jonasw, ah okay, is this a XEP?
jonasw
marc, not yet
jonasw
marc, there’s some info on the wiki: https://wiki.xmpp.org/web/XMPP_2.0
jonasw
(which may be slightly outdated)
jonasw
and also a bunch of discussion on the mailinglist
Ge0rG
And my slide deck
MattJ
marc, most comprehensive source of information is: https://op-co.de/tmp/whats-wrong-with-xmpp-2017.pdf
Ge0rG
MattJ: thanks
marc
jonasw, MattJ thanks!
MattJ
marc, "XMPP 2.0" isn't anything formal, and doesn't exist. We're just doing some review of where we are, and where we are going, and what feasible changes we can make to the protocol to make everyone's lives easier
MattJ
Back when XMPP/Jabber began, most of the popular IM networks would disconnect you from one location if you logged on from a new location
MattJ
XMPP supported multiple connections long before everyone had smartphones, laptops, etc.
MattJ
and back then, it aimed to do clever things like figure out which device you wanted to receive messages on
Archas joined
zinid
Now this is not required and even detrimental
marc
MattJ, I understand and I'll read the slides etc. to be up-to-date, thanks :)
Flow
MattJ, I always wonder if that priority based routing was clever even 10 years ago
Flow
Or what that rationale for that back then was
Ge0rG
marc: ping me if you have questions about the slides. I gave them to a nerd friend recently and had to realize they are not meant for people without really deep understanding of XMPP
marc
Ge0rG, will do :)
Alexhas joined
ralphm
Flow: the idea back then didn't take into account ubiquitous mobile devices
Kevhas joined
ralphm
It was assumed that whole you might have multiple simultaneous connections, you'd always want messages to arrive in one of them, your 'current' one.
ralphm
(while)
Ge0rG
And thus "most avaliable non negative presence" was born.
ralphm
The assumption now is that you basically want chat-like messages to arrive on all devices, with history, and proper distributed read markers
jonasw
"and it was good" no wait
ralphm
So yeah priority is mostly useless now
Kev
I don't think the priority-based routing was actually a good idea, but I'm sure it seemed one at the time, a decade before that use case came about.
ralphm
I'm still not sure about aggregate availability / show presence.
Kev
In which way? I think that individual devices having a different status message is unhelpful for most use cases these days.
ralphm
I could imagine using priority for that exclusively
Kev
To the point that I'm sorely tempted we (non-formally) deprecate status messages, and just shove something in PEP.
ralphm
Sure, Slack has per account status and 'snooze'
ralphm
Making it explicit that way seems the way to go
danielhas left
Kev
Aggregating status locally is easy enough, I think.
Kev
But messages are harder.
Kev
I don't think it's a hardship for a receiving client to see two auto-away, one available, so mark the contact as available.
Kev
(Although it's not how we'd design it if we were starting again)
daniel
> contracts shouldn't be able to choose what happens to my archive
Kev: I'm not really sure how this would look like. Even if we change to a full jid / bare jid approach it's ultimately up to the sender to make that decision
Ge0rG
I'm also in favor of aggregate presence status, but we don't need to throw everything over for that
Kev
daniel: I'd like to make a fuller response Monday, I just noticed the PR and wanted to leave a holding message to stop it getting merged until I'm working again after the weekend.
ralphm
I think we should be precise and not talk about 'presence'
Ge0rG
ralphm: feel free to provide a better glossary
ralphm
Rather about availability-presence, user status and such
Kev
But, basically, telling an archive server that someone sending me a message gets to override the rules of my server policy has to be obeyed isn't helpful in most cases. I'm happy with (more loosely than you're doing) excluding groupchat from default access, but the <store/> thing needs more care.
Kev
More Monday :)
ralphm
Availability still has use cases, even beyond chat
Kev
Ge0rG: I would still like to work with you on XEPpifying these thoughts (although I'll do it on my own if you're still not keen).
lovetoxhas joined
ralphm
Slack status is much like user mood and user activity conflated
Ge0rG
Kev: I'm not opposed, I just still think it's too early
Kev
ralphm: And I think more matches what the typical use case needs.
ralphm
I.e. you pick an emoji and a status message to go with it
ralphm
Totally
Kev
But Slack still does presence.
Kev
(availability)
Ge0rG
There is a good case for dnd at least
Kev
I think in XMPP we could easily codify something here that makes slackishness work, along with other use cases, without needing to throw baby out with the bathwater.
ralphm
But do note that Slack also has binary availability (green or dark icon) as well as snooze indicator. The latter is per account, and I assume the former is simply a logical or.
Kev
I think <status/> is going to be a victim in this.
ralphm
Indeed, as well as show
Kev
I think we keep show.
Ge0rG
But but but but I want custom text status, or at least Emoji
Kev
But I think we codify some rules of how to do a trinary logical or on it.
ralphm
Ge0rG: please read again
Kev
Ge0rG: Yes, but I don't think <status/> is fit for that per-account use. I think we PEP that.
ralphm
We'd move this to a PEP nice
ralphm
Node
ralphm
Like User Mood and User Activity XEPs
Kev
And probably replacing both, if we're honest.
ralphm
Sure
Kev
Well, or combining both.
Ge0rG
Kev: persistent or ephemeral pep?
Kev
If we changed User Mood into an emoji :D
ralphm
Without predefined items
Kev
Ge0rG: persistent.
ralphm
Even though they are extensible
blablahas joined
Ge0rG
Kev: I think I still have some junk in my pep (different account) from a client that I tried some years ago
Kev
I've added to my list of things I need to cover in the xmpp2.0-not-called-xmpp2.0 Informational XEP.
Kev
My intention is to write a XEP summarising Ge0rG's slidedeck, together with our current best guess on how we'll approach solving it.
Kev
Mostly so that we have this tracked in some way that the XSF's process understands.
Kev
Right, I'm going back to hiding my XMPP and Mail clients again :)
Kev
o7
ralphm
I guess we can fill those summit days easily
Valerianhas joined
efrithas joined
Syndacehas left
Syndacehas joined
ralphmhas joined
sonnyhas joined
Steve Killehas left
marchas left
sonnyhas left
sonnyhas joined
efrithas left
ralphmhas joined
Kevhas left
vanitasvitaehas left
Valerianhas left
Zashhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
uchas left
uchas joined
ralphmhas joined
la|r|mahas joined
Archas left
Valerianhas joined
blablahas left
Steve Killehas left
lskdjfhas joined
lskdjfhas left
Alexhas left
lskdjfhas left
Guushas left
uchas joined
uchas joined
Tobiashas joined
la|r|mahas left
la|r|mahas joined
Guushas left
lskdjfhas left
jerehas joined
lskdjfhas left
lskdjfhas left
sonnyhas left
sonnyhas joined
SamWhitedhas left
lskdjfhas joined
lskdjfhas left
lskdjfhas left
lskdjfhas left
ralphmhas joined
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
Steve Killehas left
lskdjfhas left
jerehas joined
Tobiashas joined
la|r|mahas joined
lskdjfhas joined
Tobiashas joined
nycohas left
vanitasvitaehas left
nycohas joined
ralphmhas joined
lskdjfhas joined
danielhas left
Zashhas joined
ralphmhas joined
danielhas left
Guushas left
Steve Killehas left
danielhas left
mimi89999has left
uchas left
Tobiashas joined
Guushas left
tim@boese-ban.dehas joined
Valerianhas left
Tobiashas joined
Zashhas left
Zashhas left
SamWhitedhas left
Tobiashas joined
jjrhhas left
Valerianhas joined
Guushas left
jerehas joined
jerehas joined
Valerianhas left
lskdjfhas left
lskdjfhas left
Guushas left
Valerianhas joined
Tobiashas joined
Steve Killehas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
lskdjfhas left
Steve Killehas left
lskdjfhas left
lskdjfhas joined
lskdjfhas left
lskdjfhas joined
tuxhas joined
moparisthebest
Does anyone use haproxy for xep368 or anything using alpn?