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?