XSF Discussion - 2018-03-22

moparisthebest: yes, all MUC messages go to all participants immediately, because the server doesn't know the user's notification settings

moparisthebest: if the user has "notify on all messages", delaying would be bad

but the users server may delay them with CSI

if it knows about the notification settings :)

moparisthebest, obviously, you haven’t been in the MUC of the local hacker space. People there think that using OMEMO in a public muc is a super great idea.

haven’t been there in a while, mind, all this "This message is OMEMO encrypted but your client doesn’t support it" was getting annoying.

great way to alienate people.

jonasw: if it knew. Which it can't.

Ge0rG, yet. I think it was discussed at summit that a way for the server to know would be good?

jonasw: yes. "would be good" is very far from an actual implementation, one might imagine.

jonasw: if I had some time, I'd maybe write a PEP-based proto-XEP

Ge0rG, better write a pep-based implementation first.

which just stores a list of JIDs and their respective notification settings (always / mention / never)

oh wait, we don’t even have reliable private PEP storage everywhere :<

jonasw: I didn't check in the last year. Do we have private PEP widely deployed already?

Bookmarks2 FTW

bm2 needs multi-item, persistence and private PEP. that’s gonna be hard.

I'll just stick to 0048

like I stick to google:queue.

*has CSI dealing only with presences mostly*

Maranda: was that supposed to be a /me ?

Ge0rG: I think so, we've been deploying it for years. The recent pubsub options change notwithstanding.

I *think* it's just Prosody that's had problems with PIP and things.

OpenFire and ejabberd should handle that fine I believe

So ~1/3 of the servers out there don't even have an implementation, and the other 2/3rds depend on which version they were abandoned at?

Kev, are you intentionally calling it PIP? it confuses the hell out of me because of pythons package manager being called the same.

jonasw: Yes, because that's what 223 was called.

Kev, what’s the first P for?

(the last is for PEP I guess)

Private data In PEP? *guessing*

(or PubSub)

Ge0rG: Maybe. Different people have different priorities here. Mine is mostly in moving things forward and having stuff available to people who do update servers and clients.

Ge0rG, Kev, what’s the acronym for '222 then?

PuIP?

Private Information Via Pubsub is 223

or even PubIP, just one dash and a mirror operation away from a bad pun.

222 is POP - Persisting Objects via Pubsub

I thought it was Persistent Storage of Private Data via PubSub

Which would make it PSoPDvPS

But we could shorten it down to PSPDPS probably.

You young people, no respect for history :)

https://xmpp.org/extensions/attic/xep-0222-0.1.html https://xmpp.org/extensions/attic/xep-0223-0.1.html

I’ll show you how no respect looks like!!k

(if you need to detect sarcasm/irony/bad jokes in my messages, the following regex will help: /!{2,}k+\b/. it won’t show all instances, but has a zero false-positive rate)

(I think at least :))

jonasw: what's the "k" for?

Ge0rG, it’s 1, but on my keyboard layout.

modifier + k = !

like modifier + 1 = ! on qwert[zy]

jonasw: why are you leaking your keyboard layout to the general community?

Ge0rG, because it’s 9:30am and I still haven’t gotten anything done probably.

My goal for today's morning is to get onto that VPN that didn't let me work yesterday.

so that it won’t let you work today either?

sounds like a plan

Ge0rG possibly

Raising a slightly contentious idea...maybe we should bring back SIFT

Not actually SIFT, but something a bit like that.

what’s SIFT

To solve this 'squelch MUC on mobile' issue.

SIFT's 273

Kev: what's wrong with an account-side notification prefs list that will be used by CSI?

SIFT looks like privacy lists, complexity wise.

jonasw: SIFT itself isn't the right solution here, no.

Let's collect all the requirements we had for SIFT, privacy lists and CSI and then make one big XEP to cover them all.

Ge0rG: Nothing's wrong with that, but I'm not sure that goes far enough. Unless you're intending notification settings to be very powerful - which might work.

Maybe also Message Archive.

Ge0rG: Just make sure it runs on top of pubsub

Kev: I'm not sure how powerful you think I want them for this to work out.

Like, if you say things like "Squash messages from this JID unless they have a reference payload to my JID or @everyone but make sure they're in the archive, I'll fetch them when the user opens the window"

Kev, actually, if SIFT had an "defer" action which would integrate with CSI, I can see a lot of use in that.

Kev: I wouldn't even touch archival in there. Just a tri-state of "never|mention|all"

Well, if it's not archived you've lost the ability to catch up again.

and maybe a separate global setting what "mention" means exactly, like "nickname / string-list / @all"

But in XMPP2 where it would have been archived automatically...fine.

Kev: I thought MAM was the way to archive things?

what’s wrong with getting all messages, but CSI-delayed if they’re not notification-worthy?

jonasw: it delays resync from zombie state

jonasw: Are you suggesting a server should buffer messages from a 5000-user IRC channel indefinitely?

Kev, it could fetch them from MAM for the user.

no need to keep them in memory.

just a pointer to the point in the archive

If it's in MAM, there's no need for a buffer at all, the client can just request what it wants.

ejabberd does it like that I think, even with presences.

Kev, except that the client needs to do a thing the server could be doing for it ;-)

Kev: a sane CSI implementation could dump the backlog periodically and/or when a certain number of messages have been backlogged

(Which is the better model - as the client will likely only want the most recent 100, or whatever, that contains the mention that caused you to open the room, not the previous 10,000)

hm.

maybe

Ge0rG: Maybe, although then you have to communicate to the user that they've got holes that they backfill with MAM.

makes things much more complex though

Kev: we've had that before. There is the "full client" and the "thin client" model.

Kev: by "dump" I meant "send out to the client"

Kev, so the client would have to make a MAM query after each message it receives in a room where it isn’t set to "notify on everything" to ensure it doesn’t have gaps?

jonasw: Not exactly, no.

why not? ✏

filling backlog gaps from MAM is slightly challenging, and also not supported by RSM.

It's not ensuring that it doesn't have gaps, it knows it has gaps.

Kev, depends on your use-case.

I really don't want to model MAM gaps in my database structure.

Ge0rG: That's fine, you don't have to if you want to be a 'complete client'.

I can see use for CSI in a desktop client if we can work out the timely notification thing.

what’s a "complete client"?

Kev: you seem to have modelled all the required protocol flows for both kinds of client in your head. I'd love to read up on that in a more persistent way than by querying you in a MUC

jonasw: one that keeps a full local log of messages by default, without resorting to MAM whenever the user opens a chat tab

isn’t that exactly the type of client which has to keep book of holes to ensure it can fill the gaps?

As opposed to a recent-only client, which just queries recent messages when you open a chat, and backfills as needed when the client scrolls.

Hello! I'd like to extend the wiki page (https://wiki.xmpp.org/web/Tech_pages/XEP-0368) with info on how to route HTTP/2 and XMPP TLS traffic on port 443 with nginx (the ability to route based on ALPN was recently added: http://mailman.nginx.org/pipermail/nginx/2018-March/055798.html ). If it's possible would someone set me an account on wiki.xmpp.org? Thanks in advance!

Ge0rG, ^

Wiktor: please send me a message with your desired username (Wiktor?) and your email address for the password delivery.

Looks like I lost my privileges after the great wiki disaster of 2017 :/

s/wiki //

actually, the server was a tad late. it would’ve been a great fit for '16

"great wiki disaster" :O

Wiktor: The current content of Tech_pages/XEP-0368 is very raw. It would be great if you could also add some structture :)

anyone a suggestion for a wiki page name for that bookmark autojoin discussion?

Yep I noticed that, I need to reformat it anyway as some sections (like SRV records) would be the same for all methods.

like maybe an intro sentence what the page is about, an auto-generated TOC and then headings for different implementations / common settings

jonasw: Easy Bookmarks™

and add a link to it on https://wiki.xmpp.org/web/SRV_Records

Ge0rG, asking to be sure, do you have the power to move pages? :>

SRV Records must be extended with xmpps-client too

well, a little bit more work than I anticipated but it's do-able :)

jonasw: yes I do ✏

Ge0rG, nevermind. ✏

the inverted highlighting of poezio really leads to low contrast

I turned it off for that reason

you want my irssi theme

jonasw: I'm not sure I do.

/theme irssi

I'm always very hesitant to change themes.

jonasw, would you be ok with merging it upstream?

Link Mauve, didn’t I already?

Oh right, indeed it’s there.

Hi, I was looking at XEP-0333 as I was under the impression that it was the preferred way to synchronize state between XMPP clients.

But after reading it I'm pretty convinced this is not a great way to do it, as it requires sending such state to the recipients, as the “Security Considerations” section already points out

XEP 333's not good for synchronising state between your own clients, no. Only for sending markens back to the sender (and I'm not convinced it's great for that either).

And I'm pretty sure you can do 80% of that using chatstates and receipts :)

Chatstates and receipts have similar issues 🙂

Anyway, I was wondering if there is a better XEP out there for synchronizing such state?

ThibG, no, but the question comes up regularly

ThibG: What exactly do you want to sync and between what?

Which state are we talking about in this case?

Unread markers?

yeah

I have a model for how we do that, which I discuss briefly in bind2.

*your own* unread state?

Yes, your own unread state

But there are still more parts needed. If you need this Now, I suggest the best thing is to store the most recent read messages for each contact in PIP, and go from there. It's not perfect, but it'll do.

Yeah, Kev had ideas for that

I don't “need this Now”, it's just that it's a pain having multiple clients and having notifications for messages I have already read. I was looking for a XEP to implement in clients, but guess I'll wait

I think you generally don't really want to know what's read, but what's unread, and that needs the cooperation of the archive.

ThibG, if the clients send chat markers, it should work. some clients send, but ignore inbound chat markers, so you might have a chance there. at least for some cases.

Well, s/needs/is easiest done/

jonasw: I think Chat Markers for this is very nearly the worst possible approach ):

I think the PIP approach is mostly workable, but not great, and the cooperation of the archive approach is best, but probably a little way of.

s/of\./off./

jonasw, it works when the clients send chat markers, right. But it requires telling the recipient what you have read and what you haven't, which you might not want to do.

yeah

Also, the XEP advises against sending them if the recipient doesn't advertise support for it

And it requires your archive saving markers, which it probably won't, and your client querying MAM back to find all the last read markers for your conversations, which you also probably don't want to do.

And most clients respect that, so the synchronisation depends on what the recipient supports 😕

I'm sure it's possible to come up with a worse mechanism for solving this problem, but I think it'd require some amount of creativity.

ThibG, do they? I’d advise clients to ignore that and send always.

jonasw, yeah, Dino and Conversations at least seem to respect that

Kev, got your point

:)

I think conversations wanted to move to ignore that at some point. but I may misremember.

ThibG: Really? So this would only work while the recipient is online?

ThibG: Conversations even adds a <store/> hint to make this work for offline recipients.

hm

I agree this is a mess, but I don't see we have anything better to offer right now.

Holger: I think my PIP suggestion is better Right Now, albeit unspecced.

At least, I don't think there's a XEP for it. I remember writing this down a while back.

What was PIP again?

harhar. I'm working on a bug that's caused by a client falling for the good old "Are you there?" -"No!" joke.

Anyway I meant we have no better standard solution, of course. I can easily imagine better non-standard ones :-)

Private PEP.

(ping got responded to with an error, which didn't prevent a timeout)

(223)

PIP, PEP, POP, is there a PAP?

PAP and CHAP.

But only in a PPP context ;)

PEAP?

And PUP

Kev: Ah so nothing non-standard on the server side.

Acronym creators were probably on PCP.

Holger: I think you can do something that's a usable stopgap with only 223 on the server, yes.

But it's significantly less good than doing it properly.

Yup, I see.

Holger, ok so the thing is the sender needs to set the message as “markable” for read markers to be issued, so if the person you're conversing with doesn't do it, you don't have synchronized state…

ThibG: Ah right, I was thinking of the previous step, doing service disco to decide whether to set "markable" (#5.2), which assumes the recipient to be online and doesn't cope with multiple devices.

ThibG: But your step is the relevant one here, yes. Still I think you could just issue markers no matter whether markable was set.

Server devs: How hard is it for you to do magic based on pubsub nodes?

Define magic

Kev, xep 400?

e.g. how hard is it for you to do something when something is pushed to a specific node?

eh

XEP 0398

Yes, something like 398.

Kev: It Depends™

But can be easy

I'm pondering writing a XEP for unread-sync based on PIP, and defining additional magic that the server can do to make it more useful.

please feature that magic and make it a MUST when the feature is available. I hate nothing more than having to infer whether a server does a thing or not

It's not the perfect protocol for doing it, but it would mean clients could get going with something Right Now, and as servers support it they'd gain the additional niceness.

except that e.g. prosody still doesn’t have PIP.

There's plugins for Prosody that syncs the nickname and avatar nodes with the vcard

I thought that was imminent/there now?

i think persistent PEP was there, but not PIP

So, that kind of thing is doable ✏

MattJ has claimed to be working on it

Dave Cridland: Openfire?

Ejabberd anyone?

It's possible to make nodes private from the inside in the newer pubsub code, if somewhat verbose.

Lacking context, but if that's does Openfire do persistent PEP, then yes, of course.

No, it was can you do magic like 398?

Dave Cridland, it’s whether it can do private PEP with publish-options assertions

I'm pondering writing another XEP that does magic when something is published to a particular PIP node.

Hmmm. 398?

vcard/PEP avatar magic.

No problem to implement in ejabberd (there's a publish event), just not sure I like such magic nodes.

Just 'can you hook code onto publishes to a particular node and/or would it be prohibitive?'.

Maybe I do.

Oh. I don't think so. Guus would know for sure. But I don't think we have hooks.

I don't mean user-facing hooks, I just mean for Server Features, if that helps.

Holger: I'm just pondering whether speccing something that isn't perfect protocol, but achieves the right result and lets client implement Right Now and still mostly work before servers are there is preferable to waiting forever for supporting the perfect protocol.

I quite like magic nodes, FWIW, as long as the magic is additional, rather than transforming the behaviour of the node.

waitwhat?

I know nothing!

we have no API hooks specific for Pubsub that I'm aware of. We do have generic stanza interceptors.

Kev: Yes, sounds good to me. I think 🙂

Kev: But if it works too well, nobody will ever implement the perfect protocol!

Holger, you're wrong. Implementation available here: https://github.com/kelseyhightower/nocode

:-)

Holger: Yes, I'm suggesting we never do the perfect protocol, we just get the perfect* features.

As part of this, what if the server makes it such that clients don't join MUCs, but the account does.

That is needed for this to work for MUCs, yes.

This general "make it work, not make it perfect" thing

Zash, I’m still confused how a client is supposed to know what to do with those type="groupchat" messages and MUC-related presences it is suddenly getting.

jonasw: It doesn't get those unless it joins rooms.

Zash, how is the "account" joined then?

jonasw: Server sees you attempting to join a room, drops that and sends a join from the bare account jid instead.

So, you know, one step closer to MIX.

And makes a note "this session joined that room"

Zash, who profits from that change?

jonasw: Anyone who doesn't want problems with dupes. Especially archive-based stuff like unread sync.

how does this handle s2s interruptions?

jonasw: People who are annoyed by quitjoins. Eaiser to have groupchats in user archives. Users get faster join sync.

When a second client joins, it simply serves locally cached room state back and makes a note that that session is also interested in that room.

makes sense

Oh and it keeps local room state on the server.

I might like this more than MIX, except for the still present abuse of resources.

Zash, but how does it cope when the s2s link to the MUC service is broken/the MUC service fails and restarts without state/…

In theory, one could evolve this into a compat layer for having MUC clients in future MIX channels,

those conditions where clients nowadays rejoin after a ping timed out or they got an error back or something like that

jonasw: Badly, I guess. Still a hacky PoC stage

jonasw: Doesn't even handle anyone leaving :)

I think the resync is going to hurt with this MUC stuff though.

It already hurts.

Because unlike MIX it's not clear how you connect with a client to a MUC that your account's already joined.

Kev: The server handles it and sends you the room state from a local cache.

MUC clients shouldn't notice anything different

I guess Ge0rG is correct in this being basically a bouncer.

yeah

So it gets all the client problems, except those that relate to connection issues to the server :)

Yeah, but you're getting a lot more work on the server than the server support in MIX.

which is great if nothing else has to change and you get 100% backwards compatibility, right?

I'm not sure which would be more work at this point, haven't been able to read the entire MIX spec yet.

I've got something half-working that can be tested to see if it's worth the trouble. Why I called it a hacky proof of concept :)

I think you end up doing the same amount of work, for something that still has issues.

Ge0rG: re CSI/MUC messages, is there any case of messages being processed by the server already? I'm not fond of the "mention" bit. Also you need to define it, it can mean lots of things nowadays with fancy new IMs solutions out there, @everyone, @here, @channel and whatnots

-xep attention

Zash: Attention (Standards Track, Draft, 2008-11-13) See: https://xmpp.org/extensions/xep-0224.html

Kev: Doing something that (partially) works now tends to be more rewarding than something that has to wait, in this case for MIX to become stable and implemented.

Kev, but most importantly, 100% backwards compat, and work *only* on the user's server, rather than on all clients, all servers, and all mix components

did anyone make that Wiktor guy a wiki account?

I'm not sold.

I'm a terrible sales person.

so of the mythical MIX server components that are done, which of them have backwards compatibility with MUC ?

because if not, they are a non-starter

for example when would xsf@muc.xmpp.org switch over?

moparisthebest : who's "wictor"?

moparisthebest, pretty sure my opinion is in the minority, but I see MUC and MIX serving different use-cases, and I don't necesarily feel that all MUCs must switch over

Guus, Wiktor asked for a Wiki account earlier ✏

MattJ, +1

MIX feels like a not-so-great model for the average support group chat

moparisthebest: I think Ge0rG dealt with the wiki

I didn't see that. He does not appear to have an account now

Do we have his contact details?

email?

Guus, ask Ge0rG

MattJ: How do you feel about a account-based MUC join module? Useful or hack that will haunt us forever?

Ge0rG?

MattJ, I mean the situation with muc on multi-client but especially phones isn't great, if mix can't replace muc and fix that forever I don't see a point

I'm not sure why it can't.

And you can add basic MIX on top of MUC fairly straightforwardly.

well one reason is it's been years and no one has implemented anything but a tiny part with no muc compatibility

I'm just solidly with Zash here, running code that works *now* is the way to go, vs duke nukem forever code that might be better in the future

We've not got the spec right for showing how straightforward these concepts are yet, and I think that's a part of why there's limited adoption.

But we'll get there.

And I'm not saying this will solve all problems. I just wanna know how useful this hack I made is.

I don't think there's anything that stops hacks on MUC now to make it better. I'm not sold that it can actually solve everything fully without essentially becoming MIX>

Which, at its core, is largely just about less overloaded addressing and presence semantics.

while that might be true, it doesn't need to solve everything, perfect is the enemy of good

moparisthebest, crude hacks is what got us into the carbons/mam mess though

is it better with them as crude hacks or before when multi-device was useless?

better, but also still bad

in a different way though

if we had went with XMPP2 routing/addressing right away, things might’ve been much better.

Guus: https://wiki.xmpp.org/web/Special:RecentChanges

Ge0rG argh, I somehow missed that.

tx

jonasw, crying over spilt milk? hehe

it's easy to say such things in hindsight

STARTLS would never have been a thing in any protocol either

Kev: Small steps are easier to take than large ones

Zash: you shouldn't use the bare JID, I think. Rather have one uuid per nickname

I think the Best thing to do is write a MUC layer on top of MIX, but in the short term it works to write a MIX layer on top of MUC. Implementation-wise.

jonasw, I don't think "all joins and parts to MUCs are synced on all devices" is a "simple" default case :P

(reading that wiki page)

pep., for the user, I think so

mind that most people won’t be joining things like xmpp@ but instead having group chats with their family and coworkers etc.

May be a default use-case, but it's not that simple, judging by the discussion on the list :p

it’s simple to do as long as we don’t need the second one :)

and it’s also simpler than the second one regarding the amout of state which needs to be kept

How can I use bookmarks as dumb JID list in all that?

Do I _have to_ use the syncing stuff

pep., add that dump jid list thing

on the protocol level: just without autojoin

yes, I just want a dumb list that I can access across all devices

hmm, I don't like the priority assumptions on that list

Where do I put my thing

pep., not sure

between the two I think

The thing is that it directly conflicts with the autojoin feature some wants

And I'm sure I'll have to patch most of the "modern" apps to do as I want

Fun(tm)

pep., enlighten me, what is the autojoin feature some want?

Sync the state across devices

Ok

Which state?

Joined/not joined

Say if autojoin is set to true, the channel is joined on every device, if autoset is false, don't join, or leave the channel on all devices

I don't like that because I have huge channels I only want to be joined to on my desktop, not my phone

moparisthebest, yeah that's another concern and it's being talked about on the ML

moparisthebest, as already discussed, it doesn't mean you can't have that

It's already been discussed to death on the mailing list

then I have no objections :)

I just don't want this syncing being done _at all_ across my devices, huge channels or not

I agree in general it would be nice

pep., then you just don't set autojoin, it's simple

just with the ability to override

Negotiate with your client devs :)

MattJ, no, not with what's being said. If I don't set autojoin clients would leave the channel

If I understand correctly. And that's an issue

I'm still waiting for someone to show me a well-designed MUC join dialog/UI that nicely abstracts semi-autojoin

semi-autojoin?

Ge0rG, join room from client as normal -> "also join on other devices? yes/no"?

Kev: my gut feeling is that the server-side MUC bouncer will solve 90% of today's problems with MUC, making it good enough™

Ge0rG, isn't that MUC bouncer called MAM?

MattJ: "also join on: [ ] Desktop [X] Mobile [...]"

Please no

What about tags?

Gaaaaah!

Zash, "also join on: [ ] Desktop [X] Mobile [...]" ?

:P

Ge0rG: Of course, MUC solving 90% of problems already is the reason for not bothering to fix it.

MattJ: so it would add a bookmark on success, and set the bookmark's autojoin depending on your choice, and set local autojoin accordingly?

Like, roster groups. Tag with whatever you want. Make your client autojoin based on that.

Zash, now

*no

Kev: MUC is solving 90% of the problems we had in 2002.

Zash, adding semantics to roster groups seems like bad

Ge0rG, the way I see it, any sensible client maintains a local (persistent) list of rooms it is currently joined to

jonasw: That's not what I said.

MattJ: good luck matching that list against three sets of remote bookmarks.

Zash, so two disticnt set of tags, one for determining whether to join and one to show to the user? :(

jonasw: Could be tags/categories in the current bookmarks.

Ge0rG, that can't be helped...

Ge0rG, îtym one set, because any sensible library will abstract that away from you :)

MattJ: what you just proposed is the technical background. I'm interested in designing the transition UI for adding a MUC to any of the lists, or moving a MUC between them

Ge0rG, I already said

> 13:44:18 MattJ> Ge0rG, join room from client as normal -> "also join on other devices? yes/no"?

Ignore my 5min timezone issue

MattJ: running off grid power?

pep.: "This client auto-joins [ ] All bookmarked rooms [ ] Bookmarked rooms tagged [autojoin-on-mobile]"

MattJ: besides, as there is no notification mechanism for bookmarks currently, it won't work anyway:>

Organizing bookmarks is messy already, can haz tags or something?

Zash, yes so when you add a bookmark you still have a similar question to answer

Ge0rG, we're talking about fixing that, so let's fix it

Tag it or not

And tag it with what

Zash, I’m all in for roster-like groups on bookmarks

jonasw, yeah that might be nice

I would still want what Zash said above

jonasw: And then some enterprising client dev can experiment with using that for semantics to see if that's good or bad :)

Have a choice wether the client is going to autojoin or not

Zash, it’ll be bad, because having an "autojoin-on-mobile" tag in your roster view is ugly

MattJ: so something like this? ``` Groupchat JID: [xmpp@chat.yax.im] Nickname: [Power user ] [+] Advanced options +- [X] Join on other devices +- Password: [ ] +- [ ] Show password [ Cancel ] [ OK ] ```

jonasw: I mean the client could have a free text field for autojoining things with named tags.

Zash: the only kind of tag I see as viable for bookmarks is to put them into roster groups

Ge0rG, with regular people jids?

pep.: yes

pep.: so I can have my family MUCs in my family group

Do we /need/ to autojoin other clients?

Zash: yes

Ge0rG, that means I'm gonna send presence info to all these mucs?

pep.: no?

ok, how would that work then

Notifying about 'other device joined this room' + MAM might be enough to make a nice UX?

Also how do I know it's a MUC

Show a new "conversation" or whatever ui you use

pep.: you add tags to the bookmarks, and then let the client use these tags in the same way it would use roster tags

Ok so just a UI thing

pep.: exactly!

sure

Zash: you are probably right.

Zash: but this is a huge step from where we are right now

test

Looks to be on

Test

seems to work today

go?

XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

0. Welcome + Agenda

Who do we have?

present

Me

o/

Martin excused himself earlier.

OK.

Any (additional) points for the agenda?

I don't think so

as mailed, on the financial stuff.

Ok, we can do that today, I think.

1. Minute taker?

...I can do it

Thanks

2. Financials

As layed out in Guus e-mail there are some things we should discuss w.r.t. our financials.

He asked a few questions:

1) What are our sources of funds, other than sponsors? 2) Who are our sponsors? 3) Are we properly treating our sponsors? If not, how do we improve? 4) How do we safe-guard the proces of collecting funds?

On 1) I think we can be pretty clear: none right now

did we ever have?

What we have done in the past is sell hoodies/t-shirts, but never as a way to make money

1) we can ask for public donations

more to cover costs around the XMPP Summit / FOSDEM

2)3) we need to map the sponsors journey

ralphm, although I didn't think of that, I do agree with your definition of that.

1) oh gooodies, of course, but the same questions goes on and on: who's gonna take it? how do we follow up and control? etc.

I'm ok with not having a different source of income than sponsors, by the way. 1) was just to make sure I wasn't missing anything.

2) I believe, but I don't have information from stpeter, is that we have two active sponsors, right now: Erlang Solutions, Inc. and USSHC, with the latter only in hardware

1) can donations be automated by any third-party platform?

2) is where things get a bit awkward. We're listing sponsors on our website that do not seem to exist (as an organisation) anymore.

Yes

2) a cleanup needs to be applied, indeed

and that is also unfair to people who are actually sponsors (and would discourage new ones)

I note that I didn't include the FOSDEM/Summit sponsors, because those are different in that respect

2) we can already remove the stopped and renamed companies, can't we?

Mattj, that's a concern that I had, which is why I added 3) to my list of questions.

FOSDEM/Summit is punctal

s/punctal/punctual

did we ever check if other sponsors than the ones just listed by Ralph indeed stopped sponsoring?

Or did we stop collecting money from them, without them actively pulling out?

how can we check that? on the bak account logs?

https://xmpp.org/community/sponsorship.html lists our current process, and we're mostly abiding by that

I know for a fact that ESL remains a sponsor (disclaimer: I used to work for them)

I'm assuming, but do not know for certain, that our Treasurer would know.

Guus: sponsorship is a for a limited term (1 year), there's no automatic renewal

ralphm, ok, that's fair. In that case, I feel that we should explicitly ask for a renewal, each year.

the renewal should be re-processed by humans at the same date each year, yes I know it is easy to say 😉

Guus: agreed

when?

as I wrote in my mail - we're not a for-profit organisation, but having some funds at hand can help us greatly.

January?

Then we use the FOSDEM to followup and close

“Sponsorship applies on a calendar-year basis. Sponsor funds received in the middle of the calendar year shall be pro-rated accordingly.”

So I think that maybe December is more appropriate?

I'd like to propose that we reach out to our old sponsors to see if they are willing to renew for this year.

(and do again so in December, for next year)

Which would make it a good task to add to the list for newly-elected Boards :)

agree

+1 on Guus' motion

MattJ, I'd prefer to task our Treasurer with this (or an ExOfficer), not Board.

+1

.

I really mean that Board needs to make sure this happens

ok

Shall I work with Peter on this?

Ideally all sponsorship stuff is handled by a single person, it's easier

Agreed

meh, bus-factor.

but a single person is better than no person 🙂

As long as it's documented, it shouldnt matter

Right now we're in a fairly unclear situation

Indeed

I'll talk to Treasurer to get sponsorships renewed.

let's move to the next item.

is anyone a titanium sponsor?

as MattJ says, can it be documented?

jjrh, currently I think the answer is safely 'no'

titatium is sooo outdated, it's vibranium now...

documentation seems sensible.

lightweight is ok

Go straight for unobtainium

hehehe

Ralph, you still with us?

yes

3. GDPR

This an interesting topic.

(ping jonasw)

I’m here

but maybe not for long

I think the XSF looking into this could be helpful to the community

(ping pep., Ge0rG, too)

I am not aware (because I'm not involved) in IETF efforts around this.

aware of

I also think it's important to explicitly state that this is at best advice, and indemnify ourselves

What kind of advice should the XSF provide?

!

Given agenda item 2, I'm not sure if we are in position to sponsor a lawyer, FWIW.

Ge0rG, https://trello.com/c/t79C3Yds/307-gdpr-advice for example

The GDPR is an interesting topic indeed. I'm working in a company full of GDPR consultants, so I can get things addressed.

that would still be awesome

Ge0rG, that would be awesome, please do

pep.: however, they are all at 120% capacity due to commercial clients asking for GDPR advice.

Yeah it's going to get packed for the following months/year

Yup.

People realizing it's time

plenty of resources are already available, it's a matter of taking the time to process those, and peer-review

I suppose the advice will turn out as something like (a) have a ToS / data policy. (b) let the user explicitly accept that (c) no idea for contacts' data

Ge0rG: I have also a bit knowledge about the GDPR, I can jump in here too

Ge0rG, the federation aspect is the key issue here, local service can be solved with ToS as you mention.

GDPR == General Data protection Regulation?

winfried: I'm trying to gather inputs for a data protection policy for yax.im, but please see what jonas said

jjrh, yes

We can also get ideas from email providers

Ge)rG, winfried, jonasw, can you guys sit together and come up with either a sensible bit of information that applies to XMPP usage, or with specific questions to Board, if you need anything from them?

Guus, I formulated specific questions

Guus: I suppose we can

in the trello thing

https://www.eugdpr.org/ https://en.wikipedia.org/wiki/General_Data_Protection_Regulation

I am not a lawyer. The most practical advise I can give is 1) get a lawyer, 2) document what data your own service collects and why, the definition of Personal Data is pretty broad and includes things like (indirect) identifiers. 3) Establish policies around retention and deletion of that data.

jonasw, I've seen them, thanks.

and I think they cover our most important issues

jonasw: do you think the Board can answer those?

Ge0rG, no, but what other type of questions could we bring to board?

ralphm, yeah, no (1) is basically "turn off your free service because of cost"

jonasw: "will you pay for a GDPR consultant / lawyer to answer ... ?"

Ge0rG, okay, that then ;-)

agreed with ralphm, I feel like a layer would do better, faster, stronger...

Ge0rG, can you get an employee discount on those consultations? ;-)

Guus goof for me

jonasw: I'm pretty sure that not complying with the GDPR will put you back further

jonasw: I can try to schedule them into the lunch break

ralphm, that’s why I said "turn off"

jonasw, Ge0rG, I'm also interested if it's in a language I can comprehend

jonasw: but yeah, I'm not saying it is great

jonasw: I assume that getting a proper report on those use cases will inevitably cause multiple thousands of EURs of expenses.

I suggest jonasw Ge0rG and I stick together and make an inventarisation of what to do

"yay"

what winfried said

okay, that sounds sane

I want in

we can handle that either here or in xmpp@ maybe?

I’d like to avoid yet another muc ;-)

I’ll start by translating my notes from the talk I heard a few weeks ago

I think this venue is as good as any

+1

just not during Board meeting?

Ge0rG: exact

Right

I guess that's it for now.

4. AOB

To be clear: you guys will be working on finding out if there's generic advise (more precise than 'get a lawyer') that the XSF can give to server operators?

Didn't see any

AOB I had feedback from peter on the bank account / bus factor thingy

And?

I've added it to https://trello.com/c/yNLDp6Xt/297-answer-peters-email-on-bus-factor-for-bank-account

There's an open card about the membership survey.. sorry it's lagging, but I can send out an email to board@ with my current draft for us to bash before next week's meeting

I've also talked to the Secretary, who is willing to help.

Guus, I think it’ll be more of an collection of things in the GDPR you absolutely HAVE TO look at

As in, we can spend a week bashing it, so we can make some concrete decisions in the next meeting

my preference on the bus thing is do 1, not 2, from Peters options.

(and have Alex as the co-signer)

can we vote on that, or do you guys need more time to read up on that?

I'm ok with both 1 and 2

I prefer not to do 2

I have no opinion

That's not a valid choice

3

I think it would be good to think about these options and decide our direction next week.

Sounds good to me

ok

So that everybody can form an opinion

MattJ, on that draft: please send it.

indeed

5. Date of Next

+1W

6. Close

Thanks all

thx all

wooa, that was fast

one last remark, if you induldge me

XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

https://trello.com/c/sBcxZrGZ/299-plan-and-organise-a-meeting-for-board-prios is not going to happen.

we're postponing it for weeks now.

let's archive this, and move on

I am waiting for answer since weeks now

I can't schedule

that's what I mean: there's no progress on this. We're three months in our tenure.

and we're having other stuff being blocked by this.

rather than postpone it, it would be nice that everyone answers

I'm not asking for postponement, I'm asking for it to not happen, and be removed from our Trello board. I've been doing that for a couple of meetings, each time that was responded to with 'lets see next week'.

sadly, todays meeting was gaveled off already.

I will, however, motion this again next week. I strongly feel that we should move forward.

jonasw Ge0rG pep. can we make an appointment for the GDPR discussion? I have to leave now.

winfried, sure

I’m probably the most flexible of all of us, so I’ll let you sort it out. saturday night and tomorrow between 10:00 and 14:00Z won’t work for me, otherwise I can probably arrange most things.

(and no wednesdays)

winfried: I prefer 0800Z to 1500Z on workdays.

Tomorrow 1300UTC?

winfried: 👍

nooo

that’s exactly in the time frame I opted out

jonasw: your message was TLDR :P

m(

jonasw: oops, didn't read well...

seriously though, taht’s not going to work for me :)

monday march 26 at 10:00 UTC?

winfried, wfm

10:00 UTC will be 12:00 CEST after the DST change, right?

*hmpf*

9:00 UTC will work for mee too :-P

Worksforme

so it is: monday march 26 at 10:00 UTC this muc

btw jonasw, good questions on the trello board

See you monday!

Jonasw, i'm tempted to remove the related card from the Board board, until there's something for board to act on

do you see reason to keep it on there?

Guus: please keep it for documentation purposes.

Guus: also in case the GDPR-SIG dissolves prior to providing results

The board process is convoluted enough, without acting as an archive 🙂

somebody™ could move the questions to the wiki, then

Ge0rG, not that arching a card does not delete it

it's still referable by URL

Guus: ah, then I retract my objections

now archived: https://trello.com/c/t79C3Yds/307-gdpr-advice#

I wonder if bookmarks2 shouldn't rename autojoin to no-autojoin. Isn't the common case that I want to join the MUC I bookmarked?

flow: say what?

boolean variables containing a negation are one of the worst things you can do in logic.

`if (!no_autojoin) { WTF! }`

Ok, then stick with autojoin but default to true

flow: autojoin has a bunch of problems, but this one isn't it.

Ge0rG, I think sometimes those details are important

If we give people the imression that you want to autojoin explicitly, while my use case is cleary that I want autojoin implicitly

flow: okay, you are right.

flow: we've had a discussion regarding proper autojoin-UX some hours ago. Feel free to scroll up

flow: http://logs.xmpp.org/xsf/2018-03-22/#13:49:11

Ge0rG, I saw that, but didn't closley follow

UX is another matter. what does whatsapp do?

It doesn't support multi-device

unless you count their hacky desktop proxied thing

Ahh right, that's the thing about whatsapp

but hangouts does, and I've never seen an autojoin option

IIRC there is only a "mute notification" option

flow: the change you propose is all about UX

Yeah

Ge0rG, I'm pretty sure it is about protocol design

flow: it is about the default value for an option, influencing the UX

only if you let it to, implementers could simply choose a different default

flow: by saying "this option should be true by default" you imply a UX change. Better we discuss that

Guus, feel free to remove

Ge0rG, I'm not implying an UX design. I just think that defaults should cover the common case and wanted to raise attention that I believe autojoin=true is the common case to start the discussion

jonasw, I guess I should start working on that EULA XEP as well

flow: I'd suggest to move the discussion to standards@, but unfortunately I haven't read up on that XEP yet myself

MLS BOF occurring at IETF, BTW - probably relevant to most folks here.

Mmmmm, stream URL?

acronym galore! /o\

Linked to from the IETF agenda, which I don't have to hand, but I reckon Google might know.

Hm, not linked

mls@jabber.ietf.org

Meetecho on http://www.meetecho.com/ietf101/mls/

(Should give audio and the jabber room, I think)

Just audio on http://ietf101streaming.dnsalias.net/ietf/ietf1013.m3u

Thanks

meetecho wanted me to switch browsers

Yeah, it doesn't work on Lynx.

On the topic of the GDPR, does the XSF itself need to do any work here?

Kev: you mean regarding data stored by the XSF?

Not strictly, I guess.

I do.

Hm, how do MUCs such as this one relate to GDPR?

And mailing lists?

*That* is something the IETF and other standards orgs probably wanna find out about too.

Almost certainly.

I would *think* whatever applies to email would apply to xmpp, and whatever applies to mailing lists would apply to muc? maybe?

And the wiki, which contains historical employment data, etc.

Kev: So we need a data protection office who will remove all PII from the wiki upon request

I'll see if I can find out what the IETF are doing.

I'm not in a position to assert what we need, just asking for Board to confirm that we're doing whatever it is that we need to be doing :)

it contains data on people who put the data there themselves and can remove it themselves right?

Presumably, and possibly. I have no idea what the GDPR's stance on any of this is.

winfried, Ge0rG, you’re aware of the DST change in Europe this week which puts our meeting at 12:00 CEST?

jonasw: I am

I am

good :)

Zash, this muc announces itself as publicly logged IIRC. this probably activates article 9 (2) (e) which means that the XSF is not liable even if I publicly talk about my sex life here. well, not liable w.r.t. GDPR at least.

same goes for mailing lists etc

the tricky part is with things which are supposedly private

Kev dwd we should check first if the XSF is subject to the GDPR

Kev, and yeah, the wiki stuff is also covered by that I think

winfried: That was my question.

another person told me xmpp in general is fine because GDPR said you can use/send things that are required to do what the user expects, or something

this again was not a lawyer

or something. Seems legit

well I paraphrased :)

moparisthebest, that’s not true if Article 9 (1) applies!

Registered in the US, not explicitly targeting EU citizens... I should reread the articles on it and check the WP 29 opinions before answering that one...

but really, if email is ok, xmpp is ok, would EU have created a law banning email?

moparisthebest, who knows. Wasn't there something about git history as well?

otherwise I guess all email/XMPP servers will have to move to non-EU places, and soft-ban EU people...

moparisthebest, Well. Maybe.

moparisthebest, They could easily have come up with a set of laws that means they have inadvertantly affected normal email use.

https://law.stackexchange.com/questions/24623/gdpr-git-history < for fun

moparisthebest jonasw I think XMPP is *generally* ok, but we must check all (edge) cases carefully before shouting anything

dwd, yea that's what I'm semi concerned about, wouldn't put it past politicians

If the politicians can't email anymore, then the thing will get fixed pretty fast :)

from a high level overview, it seems like this legislation was squarely targeted at walled gardens, where these regulations would be simple to implement

Compare roaming. Roaming affected EU MEPs pretty hard, since they went between Brussels, Strassburg and their home all the damn time.

Zash, no..they'll just use FAX

Zash: except that EU MEPs never see their phone bills

Sure they do

Zash: I bet they don't. Otherwise it wouldn't have taken a decade between the first iphone and the removal of roaming fees.

Ask your MEPs

Zash: they all have a business phone provided by the respective government.

Finally no roaming in Europe => Ze Germans are complaining that it took too long.

SaltyBones: I hate the mobile ISP oligopoly, with a passion.

Anyone interested in reviewing MLS specs from here BTW?

dwd, you mean the XMPP adoption for it?

Ge0rG, that's what jmp.chat is hoping to fix :) one day...

State teleco monopolies weren't all bad

Zash: oh really?

Zash: you have examples for them not being bad?

(Sweden doesn't count)

Ge0rG: How do you do emergency calls in the middle of nowhere?

I dial 911 and then my android phone reboots

Zash: sometimes you can't, because of lack of coverage.

and sometimes the 911 handling code is never tested and crashes

(this is a somewhat common problem...)

smartphones! technology! yay! :'(

Zash: the German ex-state monopolist is successively switching DSL connections from regular analog POTS to VoIP. In case of a power outage, you can't call the emergency any more.

There are solutions for this like UPS's

if you're going to replace someones POTS line this should be a requirement

jjrh: it's not. they are. No UPS.

yeah I believe it - but it should be a requirement by law. power the modem/router and a PoE switch (or ata). It's a safety thing.

911 also needs a automated system to test 911 service - aka dial 811, and for the next 60 seconds you can dial 911 to test

yea that would be nice

especially for testing if your android phone is one that'll crash :)

pre-emergency

exactly - all sorts of situations really

Ge0rG: Back in the olden days, there was copper cable that went everywhere. Later, there was near 100% GSM coverage. Now, with whatever G number we're on, if you are outside major cities, good luck.

jjrh, that’d be a good thing indeed

unless you dialled 811 in an emergency situation :)

Imagine the RoI of covering hundreds ouf thousands of km² with coverage, when like three people live there.

and less than 1 person per km²

Zash: you wanted me to tell about the benefits of formerly-state-owned telco monopolies.

Ge0rG: No, they suck.

ge0rg: they pay quite good salaries.

Ge0rG: Was better before the "former"

Zash: the German former-state-monopoly is required to proive phone lines to _any_ address. RoI doesn't play any role there. But they are not required to proivde Internet connectivity, so there are still places where all you can get is either ISDN (64kbit/s with a per-minute fee) or something like 2mbit/s DSL

Ge0rG: No idea if that is the case here (anymore)

or satellite Ge0rG ? (is that an option there)

Interesting talk last night on satellite broadband, BTW.

Although I basically understood none of it.

moparisthebest: you never used a sat link, did you?

moparisthebest: you never used a sat link, did you?

Ge0rG, no but as I understand it, throughput is fine, but latency is awful

still better than 64kbps dialup though right?

Lots of stuff on latency too. Short end of satellite is 12ms, which surprised me. (Longer end is 480ms, it mostly depends on the orbit choice).

Further north you basically need polar orbits to get any coverage at all AFAIK

non-equator orbit requires fuel and is really expensive right?

it's been a long time since I read anything about it

Everything requires fuel

You benefit less from the earth already rotating in the general direction you want

Duno about exact differences

moparisthebest: dialup has better latency, and bandwidth on most sat links is limited, so you pay per gigabyte

The "affordable" ones are equatorial, so you end up with 1s rtt, and the low orbit ones typically only offer very low bandwidth, and cost an arm and a leg

and with dialup you can't download a gigabyte within an entire month so sat still sounds better :)

Well. Russia launches at around 42 degrees, as I recall, to avoid launch failures hitting China.

yea I was under the impression all affordable ones like for homes were equatorial

and I guess that doesn't work too far north

maybe, I don't really know

Well, hard to get a geostationary orbit anywhere but equatorial.

Geostationary orbit can't be not equatorial. If orbit has tilt and rotation period equals 24h it is called geosynchronous orbit

Projection of such orbits on surface draws big 8-shaped traces

could probably feed that into The ONE

The sun does something like that too iirc

ANyone up for reviewing https://datatracker.ietf.org/doc/draft-ietf-mile-xmpp-grid/ ? Basically using PubSub for incident management (crybersecurity incidents, really).

dwd: is that used anywhere? My employer is very interested in cyber, and I'm very interested in jabber.

Ge0rG, It's early days, but there is a load of interest.

Is "cyber" still used?

Last time I reviewed a cyber related xep it was horrible.

Ge0rG, This one got serious work from PSA, and looks sane to me.

oh, PSA is at mozilla these days?

jonasw, Yes, but mostly doing W3C work currently.

that’s a funny author list. A Pope and a Saint.

> In SACM

close!

That's great

So XMPP-Grid is developed in MILE, since it has the simpler use-cases, but it's also being looked at closely in SACM, which is Security Assessment and Continuous Monitoring.

I'm confused by (Americans?) saying JSON with the emphasis on the ON, and not pronouncing it like "Jason".

I've always said jace like mace on on like, turn the light on

I think it goes both ways here; I hear both pretty often at least, not sure if it's a regional thing or not

then again I can probably count on 1 hand the number of times I've spoken not typed JSON

still not as bad as when I had to say lighttpd out loud without prep though

You mnean lie-tuh-tuh-puh-duh?

mean, even.

more like light http... lie http..., look it's spelled like l-i-g-h-t-t-p-d

nginx is another fun one, what's with web servers?

ligh tuh-tuh-pud?

Everyone knows that's pronounced in-jinx. Obviously.

Laj-ty

If we have MIX messages in MAM on both the MIX and the user's server, who's responsible for stanza ids?

Ge0rG, both?

stanza ids can have a from IIRC

the attribute’s called @by

How am I supposed to sync that mess in my client, then?

always ask the MIX server, be happy.

While trying not to cry.

(and use the stanza-id from the MIX server)

I don’t quite get the point of duplicating the acrhive across the network, especially since I’m not sure whether the s2s issues are fully sorted out yet

Create a separate table for M:N relationship between messages and their ids?

Ge0rG, no, use the MIX stanza-ID for MIX messages, and your servers stanza ID for all other.

jonasw: they aren't

annotate (or figure out) which archive to query for each message type

of course, that’s tricky depending on your archive model

I’ll add that to the design consideraitons for the jabbercat archive

jonasw: Hm. How am I supposed to query my server for "everything after MIX ID x"?

not?

you’d look at the last non-MIX message obviously. or you take the stanza-id from your servers archive from that MIX message

But I'm supposed to ask my server when reconnecting?

ask your server for what?

My head just exploded.

I’m not going to mop that up.

How about we fix the mess so we can finally have everything the users archive?

-EPARSE

in

Packetloss between brain and poezio

Zash, fix the general issue that split brain conditions will always occur and/or specify proper syncing in MIX :-)

jonasw: s2s-smacks?

Or have one archive query the other?

not sufficient for longer partitions.

Or cry?

the latter would work

but that’s not specified anywhere

Does it need to?

And, is that what Matrix is supposed to be?

it would be good to have that writetn down in MIX so that noone is surprised like "oh, we need to do that for things to work?"

And where's the blockchain?

the blockchain is illegal now

Gooooood

yeah, it made my day yesterday

Does that make git illegal too?

Zash: no. Git will become illegal on May 25th

"By submitting patches, you realize that nothing can ever be truly deleted."

s/submitting patches/using the internet/

but no, EU will just legislate it away magically

My questions regarding MIX were provoked by flow's mail

moparisthebest: just stop bashing the EU. In the US of A, Zuck is playing the innocent while sitting on millions of data records he obtained illegally

Wow. My current level of sleepyness and the length of that email are not friends.

Ge0rG, illegally or that idiot users gave to him willingly?

moparisthebest: illegally. In Germany it's illegal to collect PII without consent, and Facebook is profiling me despite me not having an account.

Wait how does the EU pass laws now?

seems to me this GDPR business is creating more problems than anything it's solving

Don't they pass directives that countries are supposed to adapt?

moparisthebest: it's mainly creating problems for people who think they can trade *my* data without restrictions

Ge0rG, lol don't get me started on germany's dumb PII laws, for medical trials we need date of birth, that's illegal to collect in germany, however, it is legal to collect how many days old you are today, march 22nd, 2018

what genious politician came up with that one?

moparisthebest: data is like oil. If you spill it, somebody else has to pay millions to clean the mess

what email are we talking about

jonasw: MIX review I think

oh, so not from right now

moparisthebest: you should fire your lawyer

I liked the start and was distracted

jonasw: https://mail.jabber.org/pipermail/standards/2018-March/034668.html

I could use that email2epub thing right about ... tomorrow.

too many unread emails in threads which concern me

Was there a thing that lists current CfEs?

Zash, no, CFEs aren’t tracked

XEP-0092 and XEP-0048 are closed, the others are still open

eh

incorrect, second

The Others

XEP-{0092,0122,0131,0141,0229} are open.

XEP-{0048,0066} are closed

Don't think I touched the >100 ones

SHIM is a dependency of PubSub IIRC

(SHIM being XEP-0131)

And what does that tell you about xep60? :) ✏

it grew for way too long?

s/touched/implemented/ might be more accurate

minOccurs='1' but no max?

(yes yes, non-normative schema)

I wish we had a way to express normative schema

We do, we just say 'this schema is normative'

Kev, yeah, but a lot of things we do can’t be expressed with XML schemas easily

Ah. You mean a schema that is capable of expressing the normative text, rather than a way of expressing that the schema is normative.

I think.

yeah

that’s what I meant.

As you were.

So we would be just one step away from implementing the protocol code right from the XEP? Yay!

Oh, good call, we can express the schema through C++.

Result.

I wonder whether a specialized XML Schema variant (re-using the scalar types, but re-doing all the complex type stuff) would make sense.

I remember Link Mauve actually thinking about that for a while for https://hg.linkmauve.fr/xmpp-parsers, having some macro with a DSL to generate the code for the parsers :-°

Zash, the more I think about it, the more it seems that having the users server sync the archive from the MIX server is the way to go, *iff* we want to have the users server have a copy of that archive at all.

jonasw: That would work for MUC+MAM too.

yeah

simplifies things

for the client anyways

Zash, have you checked mentally whether that fits with prosodys model of $date-$uid archive stanza IDs?

Just replace direct messaging with a MAM subscription and you are done.

Having to query MUC-MAMs is somewhat messy

jonasw: That's not Prosodys model. That's my NIH'd "I don't like databases" database.

jonasw, that, but I wonder if MAM should get an overhaul

jonasw: Prosody itself doesn't know or care about that.

Zash, okay.

Zash, that still leaves my question though :)

flow, that sounds awful.

what would you change?

jonasw: The storage API is just (user, suggested-id, stanza, ...) → (id)

I know it is a senstive topic, but given the recent discussions about MAM syncing I started looking into prior art

The idea being that the storage driver might use the ID you want it to, or might need to pick its own.

I'm not sure that MAM needs an overhaul other than ripping the config stuff into its own XEP (which is just editing), and ensuring we can fill holes.

(And we can fill holes, and we have code that works, but people seem to be dead set on believing we don't for some reason, so we might have to tweak the spec)

i'm actually not sure *what* I would change, but I have some ideas

flow, drop them on standards@?

I still need to process your MIX mail though

jonasw: Does one archive subscribing to another prevent it from making up new IDs?

The biggest thing that MAM needs is to be based on XMPP 2 routing rules for its archiving, I think.

probably, but first I'd like to look if JID hiding in MIX could be made optional

and if the overall MIX thingy can be made simpler

Zash, no, but if you bulk fetch messages it could get weird

jonasw: How?

I need to reply to flow's MIX mail, but I'd quite like to swap all of the current 369 document into my head first. I understand the design, but don't know what words we've got to describe it.

Zash, if MAM has a guarantee on being in timestamp order, you’d need to backfill at the appropriate places

jonasw: Ohglob

jonasw: That messes things up :|

flow: I think MIX *is* pretty simple, but I think we've somehow made it sound complicated despite this.

flow, as long as MIX doesn’t fall back to what MUC does with that /resource-as-nickname "abuse", I’m probably fine with it

Zash, thought so. welcome to the struggles clients face :)

Kev, the question is not if it is simple, but if it can be made simpler (without loosing functionality)

And I'm not convinced that the JID hiding is actually significantly complex, it's just one indirection lookup.

Although it was me who was pushing for not having semi-anonymous (in xep45 terms) MIXs at all, but the Summit was very clear that this is a required feature.

I sense that it's a controversial feature

I think it's a required feature, but I don't see why it has to be tightly coupled with MIX…

It could be some other XEP that comes later and isn't specific to MIX.

It seems like that's true, but I don't think it is.

So what abstract model should MAM be based on?

It would be if we were talking about fully-anonymous(fully-pseudonymous) rooms, but for the semi- model I think it does need fairly tight coupling.

what is the use-case for semi-anon as compared to fully-anon though?

As long as the MIX service is still the thing issuing the semi-anon identities it can be publishing a mapping into nodes that only the admins can read.

We've coped with this level of indirection in MUC for years and other than that we got the pseudonymous JIDs wrong, I don't think it's been a significant barrier to entry to anyone.

jonasw: The usual public MUC where you don't want people to start spamming each other, but you do want sensible moderation.

Kev, which part of moderation requires semi-anon?

Anything that involves knowing who you're moderating?

Anyway, it's late and I'm shattered, so I'm going to pick MIX up again in the morning. NN folks.

Kev, why do you need to know?

affiliations (speaking in MUC terms) could be mapped by the MUC service. e.g. if I say /ban kevins%proxy@jid, the service would translate that to "ban kevins@actual.jid" and would enforce that

You can already ban and stuff via nickname, so ... I'm too tired to have any idea of what you are talking about

you can’t ban via nickname

if your client allows that it is racy

(maybe not racy; but at least the client does the nickname->real jid lookup)

Full-anon MUCs must work like that tho

are there full-anon MUCs?

... No

So what you want is to tell the service "ban this nickname" and it will ban the user's real JID without ever exposing it to the MUC owner.

Ge0rG, yeah

except that I wouldn’t use nicknames in MIX but the proxy JIDs

in MUC that wouldn’t work because of the inherent race condition

(I send "ban X", my link is slow, in the meantime X leaves and another person accidentally also called X joins)

Is it kicks in MUC that are on nicknames?

Zash, yes

jonasw: Altho that's not as permanent as affiliation changes

Races could be mitigated by not allowing anyone else to use a recently used nickname (for x time)

Zash, that’s a bad mitigation

Why?

because my link may lag for x+1 time after I sent the kick

without a way for me to rectify it in time

and ebcause I don’t know their real jid I can’t re-invite them

I'm sure we can live with that improbable problem

(won’t be a problem with MIX)

I think waqas mentioned prosody *had* an implementation of full-anon MUCs

pep.: Yes, we used to, and it wouldn't be that hard to add again

I'd like that back, way more than semi-anon. I don't really get why semi-anon survived and not full-anon

Though as SamWhited it doesn't have to be in that XEP? it can be dealt with another XEP. SamWhited, were you thinking of something like burner jids?

Is this used anywhere yet btw?

as SamWhited said*

I don't have context of what Sam said

I don't believe burner JIDs are needed for just anon MUC

05:58:01 Kev> Although it was me who was pushing for not having semi-anonymous (in xep45 terms) MIXs at all, but the Summit was very clear that this is a required feature. 05:58:28 SamWhited> I think it's a required feature, but I don't see why it has to be tightly coupled with MIX… 05:59:01 SamWhited> It could be some other XEP that comes later and isn't specific to MIX.

(beyond what Prosody already has for semi-anonymous)

waqas, sure, but they could be used instead of implementing full-anon mucs on any server, and would also be useful not just for mucs

As long as MIX clarifies that the JIDs may be missing or may not be real JIDs, and leaves the door open. Because if it's defined in a XEP, you still want interop with clients who were written before that new XEP happened.

(don't pay attention to my UTC+9 timezone)

"Go to sleep"? ^^

Mental or physical timezone?

none of these. I just have to move that machine back, someday

And also maybe change the timezone

> "Go to sleep"? ^^ 7:23 is a good time to get up

Or maybe in the opposite order