XSF Discussion - 2020-01-13

:D that deascalated quickly.

about what was that talk, i did not understand one word

lovetox, moparisthebest didn't fall for reverse psycology, that's the take away from this

winfried, reading your comment on the PR: some believe that any libsignal wire protocol library would itself be required to be gpl compatible. INAL, but I think this is likely true

*libsignal wire-protocol compatible library

lawyer up and argue that copying some constants does not constitute a derivate work!

or something

winfried, exactly, my argument is basically the XSF isn't even qualified to decide that and moreover it shouldn't matter

it surely also varies by jurisdiction, it's a useless restriction to put on XEPs

Copyright works for the implementation, not for the principles underneath it. So if the protocol isn't described in a document with a license stating that any implementation of it needs to be GPL'd then code re-implementing the the protocol can have any license.

And the Signal protocol is nowhere described properly except in the code....

Is an implementation a derivative work of the specification?

@Zash no. Reusing the text of it for a concurrent specification would be, as would be correcting the specification.

Some RFCs include example code which tends to be BSD/MIT-ish licensed, for sensible reasons.

winfried, I'd argue that the signal protocl is nicely described, specified and document, but the constants ligsignal uses are not

and in some jurisdictions that doesn't matter, in other's like the USA there is case law about that saying it's ok for interop I think

under no circumstances should *programmers* at the XSF make legal judgements and enforce them on XEPs, in my opinion of course

@flow: it's long ago I read all the documentation I could find on Xototl (as it was called back then), and by then it was incomplete. It would be interesting to see the licensing of the protocol.

winfried: https://signal.org/docs/specifications/doubleratchet/

also I find it odd if we are going to "guarantee everyone can implement a XEP" that the guarantee seemingly only applies licenses

https://xmpp.org/extensions/xep-0365.html we should also drop this one since most people aren't able to use STANAG 5066

(sarcasm of course, but that goes to my point, once you start rejecting XEPs because you think certain people won't be able to implement them where do you stop)

flow: "This document is hereby placed in the public domain", interesting to see where those constants are defined and if these would be GPL....

winfried, The constants are only defined within the source code as far as I've found.

moparisthebest, I'm not sure what you think it not implementable with XEP-0365. It wouldn't be fun, and you'd need the hardware to make any use of it, but it is possible to write a STANAG 5066 implementation without access to any radios.

Indeed, you can use 5066 across serial lines if you wish.

and everyone agrees it's possible to implement OMEMO as long as your software is GPL

or, even if not, as long as you just don't distribute it

what's the difference?

moparisthebest, What's the similarity?

both of them are implementable given certain decisions and constraints

moparisthebest, What decision and constraint for XEP-0365?

"implementing it without radios/being able to use/test it" seems the same as "implementing omemo and not distributing it" to me

moparisthebest, But you can test it without radios - just write a simulator (or, indeed, use an existing one).

and you can test omemo without distributing it

trying to find those constants in https://github.com/signalapp.. does anybody have a pointer for me?

moparisthebest, I don't understand why you think that's the same thing.

my question here is essentially, what makes the XSF qualified to make this license judgement

I don't think it is, so I don't think it should, that's all

moparisthebest, And your view is that we should actively avoid doing so, which is rather different from acknowledging that whatever we may strive for, it might be unattainable in some edge cases.

moparisthebest: Only judges (inital, appeal and then higher appeal for each jurisdiction) are qualified to make license judgments. Until then we have to make our estimation...

yes, we should actively avoid trying to make license/law decisions because we 1) are not lawyers 2) cross so many jurisdictions as to make even the attempt useless

moparisthebest, But we also cannot perfectly prove that our protocols work. So should we then avoid making interoperable protocols?

that's different, it's something we do have control over, and what the focus should be on

moparisthebest, you seem to be jumping between "GPL-only XEPs should be fine" and "the XSF should not care about licensing"

which is it?

if the UK govt bans communication outside of $new_govt_app tommorow do we just close up shop here or

jonas’, the first being true because of the second

moparisthebest, Why is that relevant?

dwd, isn't a "we shouldn't allow this XEP because of $possible_legal_concerns_over_licensing" the same thing?

are we policing the legality of XEPs or not

moparisthebest, No.

moparisthebest, We aren't policing the legality of XEPs. We're trying to ensure that anyone can implement them without emcumberence. That doesn't mean analysing the law, it means following largely similar rules as any other standards development organisation, and avoiding cases where there is a strong suspicion that essentially nobody could implement without a constraint placed upon them (even if they might be happy in some cases with that constraint).

moparisthebest, I note that you didn't complain when we rejected XEP-0365 initially. In fact, you didn't say anything on the subject at all.

there are a billion possible constraints on people implementing XEPs, this seems like a particularly arbitrary line

We may differ on opinion on how the XSF should relate to legal issues, but I am still trying to find those constants. I really want to see them before making my own judgment on the license status of OMEMO implementations.

I don't care about XEP-0365 in particular, just the policy in general

winfried, https://github.com/Syndace/python-omemo-backend-signal/ there’s this code which is assumed to be the minimal part of OMEMO which is to be put under GPL

winfried, stuff like this probably: https://github.com/Syndace/python-omemo-backend-signal/blob/master/omemo_backend_signal/doubleratchet/cbcaead.py#L26

and, for the record, those constants feed into HKDFs, so it’s very likely that you cannot reverse engineer them by just looking at the wire format

I’m not even sure that’s possible to do with clean-room stuff, but I’m not 100% certain on how it works. maybe it is. there’s still the trademark question tho

I think it's probably fine just to copy them, it would *definitely* be fine with clean-room, but I'm not even arguing that, just that we shouldn't be trying to make those judgements

I wouldn't be at all opposed to a note about them, but rejecting a XEP because of a legal judgement we made is ridiculous

(and again, with OMEMO, seems there are plenty of technical reasons to reject it which I have no problem with)

jonas’ wasn't the double ratchet taken from a MIT licensed library?

constants are here what's the license of this? https://eprint.iacr.org/2014/904.pdf

winfried, doubt it, then it wouldn’t be split off into the -backend-signal repository (wihch only exists to isolate the GPL things)

winfried, you may want to ping Syndace about the details

moparisthebest, are you back at trying to judge the license situation? ;)

jonas’, isn't everybody here?

That's what started this whole thing

I'm probably failing at being clear, we SHOULD NOT BE TRYING TO JUDGE THE LEGALITY/LICENSE SITUATION OF A XEP

Or we get a legal team! For every single jurisdiction in the world :)

pretty sure none of us are lawyers, but I know 100% none of us are lawyers across all jurisdictions

I was trying to answer winfried 's question with the links, also constants are https://hal.inria.fr/tel-01950884v1/document

pep., I stopped trying, really

moparisthebest: trust me, lawyers won't give an answer too, certainly lawyers not because they may be sued if a judge judges differently.......

haha

https://www.dinosec.com/docs/WhatsApp_E2E_Encryption_RootedCON-DinoSec-RaulSiles_v1.0.pdf also constants here

jonas’, sure, so did I (I don't think I even tried actually)

all that's enough that likely that would be plenty for a "clean room implementation" ie, "I did not look at that GPL lib, I found the constants in these slides"

and again, that shouldn't be a consideration the XSF should make, that's on the implementor

moparisthebest, I’d like to remind you about the three options from the other day

so ralphm / dwd / jonas’ , ralphm is the one that said I should update that objective, if not and I really just want to make sure the XSF doesn't try to judge the legality of a XEP, what change should be made?

moparisthebest, I’m not quite able to parse that sentence

If your objective is that the XSF stops aiming for XEPs to be unencumbered, I think the PR you proposed is the right one.

(Which I think is another way of putting what you've been calling 'judging the legality of a XEP')

probably

my argument is basically the XSF isn't qualified to do so, so we shouldn't

Thanks for all the pointers to the constants and publications of them. Lets stat it this way: if Marlinspike claims all OMEMO should be GPL'ed because of the use of the constants, then he would not have a strong case without suing all publications of those constants that are not GPL licensed. (Wondering what constants are used in Whatsapp....)

I don't agree, but I think the PR you've opened is the right way to propose the change.

winfried, he might’ve given a license to WhatsApp for example

which is his right to do

(and which may be why he insists on GPL so much)

jonas’: true

winfried, FYI I did https://www.google.com/search?q=%22WhisperMessageKeys%22 which is slightly cheating, but you could have equally searched for "textsecure audit" or whatever

He didn't simply license to WhatsApp, they paid OWS to help them implement it: https://signal.org/blog/whatsapp-complete/

winfried: I heard my name! Happy to clear up most questions about the OMEMO Licensing thing

Syndace: great!

(sorry, now I'll be driving for a few minutes and can't respond) ✏

No prob, I was cooking so I couldn't respond ;-)

But to state my question already: is it correct that you included the WhisperMessageKeys used for the HKDF function in the GPLed part of your library? And do you see any other obstacles (except for a lot of work and code reviews etc) hindering writing a SignalProtocol protocol implementation from scratch?

Okay here I am. Yes, I had to use WhisperMessageKeys and various other constants to stay compatible with libsignal. Those other constants include more strings (I thinkt there is WhisperMessage used somewhere and a third one) and two byte constant, one being used to encode the curve a public key is correspnding to and the other being used during key derivation. All of these constants are _inputs_ to cryptographic functions at some point, most of them being hash functions. There is also one more thing I had to take from libsignal: the protobuf structure definitions, which describe how the data is encoded into bytes that are then sent to other parties. All of these things were taken from the GPL'd repository of libsignal.

Other than that the only obstacles are a basic understanding of cryptography, a lot of time to read and understand the specs by Signal, and quite a bit of implementation work.

Oh and yes, all of these constants are obviously part of the GPL'd part of my library.

It was not easy to split these parts cleanly.

(and it's a little optimistic to call it "clean")

winfried: Did that answer your questions?

protobufs could clearly be reverse-engineered from the network at least though

Syndace: yes... I already found some of those constants, two byte constants and protobuf stuf in your code, was wondering how I should weigh them.

and I don't think you can copyright constants, that's surely true in at least some jurisdictions

moparisthebest: I am not sure, especially they made the constants contain "Whisper", which is probably a copyrighted name.

This is an old trick that a lot of software uses. They embed some copyrightable material into their format and suddenly nobody can copy the format without violating copyrights.

I file that under "hacks programmers think get them around copyright laws" :)

yep, at least oracle database and apple, that I know of

actually here I don't think you can copyright the word "Whisper" either

again depends on a lot of things, including jurisdiction

Famous examples include file formats that include a little poem or the Nintendo Game Boy Classic, which only boots games that contain the Nintendo logo at a certain position.

Trademark, not copyright

moparisthebest: Yes, this is again a thing us it people can't really know/decide.

It is tricky to enforce the copyright over configurations or 2-byte constants, but it is easier to enforce when it is 'Whisper' or a longer key.

But looking at all, I come to the conclusion that it is indeed impossible to implement OMEMO without using GPL'ed code.

well that's why we are making NEWMEMO

(working title)

Daniel: good to hear, is that part of the work of the e2ee sig?

I'd say NEWMEMO is the first big goal of SIG-E2EE

that's still a legal judgement by a non-lawyer and is virtually guaranteed to be wrong in at least 1 jurisdiction right? XSF should not be even attempting to make these judgements

probably. at least the idea for the sig came from the same people who are working on omemo and newmemo

moparisthebest: It's the safe route, which is the route you should take if you have no idea

But yes, the conclusion should not talk in absolutes

safe route for, who? the implementor should decide for themselves, they know the relevant things like what jurisdiction they are in or what license constraints they have

safe for everybody who doesn't know better :D

i think omemo needs a lot of clean up that are independend of GPL questions. like fixing that horrible namespace for one

is [87, 104, 105, 115, 112, 101, 114] trademarkable/copyrightable winfried / Syndace ? :D

Daniel [19:49]: > well that's why we are making NEWMEMO I vote for OLOLO or OMENNO

MLEMOS

MLSEMO

moparisthebest: yes, this is a judgement by a non-lawyer, yes it is guaranteed to be wrong in at least 1 jurisdiction, no a lawyer wouldn't give more certainty, only a judge can and no that not a reason for the XSF to not make estimates on legal issues, we can't function without such estimates.

moparisthebest: Sorry but I can only judge that as you trying to trigger us. As I said we are not sure, thus we will go down the safe road and assume that the constants in libsignal are GPL'able

Daniel: I'd be happy if the PEP interaction got an overhaul as well :)

Zash, in more than just using multiple items in one node?

moparisthebest: [87, 104, 105, 115, 112, 101, 114] is likely copyrightable, certainly if there is no prior art...

sorry Syndace , kind of a joke question, and yes I don't know enough to say if the constants can be GPL, and wouldn't even want to guess, I don't think the XSF should either

winfried: trademark, not copyright

Daniel: Thanks for saying that. OMEMO2 has become way to equivalent to OMEMO without GPL. In contrast to what Paul wrote on the mailing list, my primary goal is _not_ to get rid of GPL, my primary goal is to create an improved version of OMEMO which does not cause headaches to everybody involved.

I wouldn't be at all opposed to the XSF putting something like a warning in a XEP "hey no one is really sure if the constants needed are under the GPL or not, good luck" but rejecting for that reason seems wrong to me

Ge0rG: it is less likely to trademarkable because it doesn't represent a recognizable pointer for a product, not as such a list of numbers. (4711 would)

Daniel: The thing with deviceid in node is weird and causes us pain (because users look at the storage and complain). Using PEP at all allowed for quick deployment but as the thing with publish-options hints at, I don't think you should be afraid of inventing something separate from PEP. There's motivation/pressure for implementing these things as long as the current OMEMO doesn't block on account of being "good enough"

well having multiple items in one node (one item per device) and not having the index node would get rid of that

i think that can and should be done

winfried: http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4807:j4jxhx.2.14

Daniel: Agreed, splitting the device list node into multiple is one of the things I want to do

i kinda like the idea of having something that isn’t pep (because you can actually hand out just one prekey per contact); but i'm afraid of second system syndrome

and overengineering everything

Daniel: A generic device registration thing would be handy for a number of things....

Zash, well if we do it _that_ generic we will never be done

Heh

one of my primary goals for the sprint is to actually have something done after the 2 days

unless maybe if we can work on 'generic device registration' during summit (which predates the sprint); but even then it feels too risky

Ge0rG: Interesting and interesting how enforceable the trademark would be when used as id string in a protocol. http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4810:4gknh0.2.2 and still all browsers claim to be 'Mozilla'...

We do have some interest in keeping track of users' devices on the server, for things like MAM.

and pep isn’t even a bad place for omemo; and a 'get me one prekey' request could potentially be done independently of that (even if the data is actually still in PEP)

winfried: I'm sure you'll want to fight that out in court if you develop a browser

Ge0rG: yeah, these are indeed cases to take to court....

BTW: https://www.ngi.eu/news/2019/08/20/user-friendly-email-encryption-possible-with-identity-based-cryptography/

(still have to see how far they really will get)

> Bart Jacobs: Speaking for myself, I don’t really have the patience for standardization and arguing about details.

hahahaha

moparisthebest: > is [87, 104, 105, 115, 112, 101, 114] trademarkable/copyrightable winfried / Syndace ? :D This reminds me of the story about Oracle using lines of a poem inside the wire format of their (database?) application. The reasoning was that a protocol could be reverse engineered without breaking any copyright laws, but poems are literature and remain protected.

yep I linked that the other day, also Apple did a similar thing within their... bios (not the right word)

vanitasvitae: Look like 10 messages above :D

moparisthebest :-D but Bart is a bit a pain in the *** for Dutch governmental bodies that are implementing broken crypto....

I've never heard of the guy I just thought that statement was funny

moparisthebest: he is professor in Computer Security and quite highly valued in that role. And he is not adverse from some controversy....

moparisthebest: he makes the news here every few weeks...

this brings up all sorts of interesting copyright questions actually, can 24603125091427698 be copyrighted? wikipedia has a simalar-ish article https://en.wikipedia.org/wiki/Illegal_number

24603125091427698 is what you get if you prepend the ASCII bytes of "Whisper" with a 0 and read it into a signed 64-bit number

(and again to be clear, this kind of conjecture should be left up to implementors, not XSF)

$2,500,000. ✏

that’s a number

It is. That's the license fee Moxie asked for from Wire when they published an open source Axolotl implementation in Rust - they licensed under MPL.

and did that work?

you are saying there is a complete implementation licensed MPL that can be used?

dwd: I'm sure that was just a generous consulting offer to ensure that Wire devs do it in the most secure way possible.

No. They wouldn't pay, tried counter-suing, and eventually reached a settlement wherein they refused to allow Moxie copyright, but they would change the license to GPL.

was this before or after the documentation was published?

He is just doing that to protect you

moparisthebest: no that can't be used because it is disputed because of license violation...

moparisthebest, Depends which documentation you're talking about.

moparisthebest, according to an article, they based their implementation on, among others, the How Secure Is Textsecure paper you linked earlier

https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7

Daniel, I know I feel safer

Looks like it doesn't use the same constants, either.

indeed

so that wouldn’t be enough, and anything axolotl-ish would live under fear of Moxie

> Daniel> i kinda like the idea of having something that isn’t pep (because you can actually hand out just one prekey per contact); but i'm afraid of second system syndrome I wonder if one could do both: Something like a basic pure-PEP based approach for rapid deployment and a PEP extension that allows to hand out a prekey only once

which makes me think that the only viable way forward is reject OMEMO, publish a statement that Moxie makes the ecosystem move towards MLS, and that’ll take a while. until then, you’re bound to OX, OTR or use a GPL-licensed client with inofficial OMEMO support

jonas’, anything not already GPL :)

My understanding is that you don't want all the prekeys / clientinitkeys visible at once anyway.

jonas’: one of the protocol descriptions linked above is 'public domain', so the pain is in the Mozie ^H^H^H^H constants

(prekeys for Axolotl/Olm, clientinitkeys for MLS)

winfried, the article I linked earlier where the Wire folks describe their issues mentions that they were bullied by Moxie even though they based their work on that public domain paper

you can be bullied even though you are legally in the clear

flow: yes I said that a few lines down

moparisthebest, which is an encumberence to me

oh man well then you can't implement any of XMPP

there probably exists a patent troll with a patent on "messages via internet"

Daniel, uh, sorry, I've missed that

dwd, because attachs?

flow, I have no idea, but I sat in a room full of cryptographers and one of them said so.

dwd, next time, close the doors, then ask for the rationale and do not open until they provided one ;)

and grey smoke emerges?

flow: And make sure you use a key with sufficient bits.

flow, I believe it's due to the same reasons as we use different {pre|clientinit}keys for each session - that is, by using a different key it makes the analysis easier.

I've been told that reusing keys isn't the end of the world

Daniel, Indeed - better than running out of them.

depends on the crypto primitive always no?

But you know. Ask 3 cryptographers get 4 different opinions

Daniel, I did float the notion of using an early reuse idea, where you become probablistically more likely to reuse a key as the server runs out, but I couldn't actually figure out a way to make it work nicely.

jonas’: I love to take Moxie head on, I had once the honer to speak right after Moxie at a conference, while I was climbing on stage, I saw half of my audience leaving. I still haven't forgiven that. (Though he did apologize for taking some of my time......) :-D

Daniel, And yes, never been in a room full of such incomprehensible arguments.

> This is an old trick that a lot of software uses. They embed some copyrightable material into their format and suddenly nobody can copy the format without violating copyrights. Wether it actually has any legal value is still to be determined, it's mostly a threat tbh. Nintendo used the same technique (the Nintendo logo at the beginning of every Gameboy game had to be part of the rom abd was verified at runtime), but I couldn't find any case. It was mostly a threat because who is going to oppose that much money..

winfried, moohahaha

(hmm, topic has changed 10 times in between)

and and you do cite Nintendo even..

:D

Anyway, summary seemed to be that reusing keys, or publishing them openly prior to use, is probably safe but it makes the cryptanalysis harder, so please don't.

makes it *easier* dwd ?

no, the theoretical analysis (to prove things are safe) gets harder, moparisthebest

ah got it, thanks

dwd: do I get it right that we are talking about the keys that need to be disposed of after use to get forward secrecy? Publishing them openly seems a bad idea then and keeping them on the server for a long time seems increasing the risk. (and still the idea of e2ee is that you don't trust your server...)

You delete your private keys

Daniel: clear, of course.... (brainfart)

"Courts have found that reverse engineering for interoperability, for example, can be a fair use." https://www.eff.org/issues/coders/reverse-engineering-faq interesting

basically all the cases there were ruled in favor of people who "had to look at the code to examine how it worked" and constants etc

so in my official opinion (read: worthless) you could implement non-GPL OMEMO just fine (but still might get sued by Moxie, though you'd likely ultimitately win in court) in the USA

moparisthebest: examining it and describing the protocol is something else as reusing copyrighted keys and using trademarked names. Reverse engineering by looking at the code and then writing your own implementation would be hard to ban, but when it contains that one key....

(though it would be interesting to look if there are cases about that)

winfried, isn't that exactly what those cases mention? 1. the Ninth Circuit ultimately found that Accolade’s “intermediate” copying (i.e., copying solely in order to discover functional interface specifications that were then independently implemented) was a fair use, emphasizing that disassembly was the only way to gain access to the ideas and functional elements embodied in Sega’s copyrighted computer program and that Accolade had a legitimate reason for seeking such access.

2. finding that Connectix’s intermediate copying was a fair use. The court emphasized that the intermediate nature of the copying (i.e., no Sony BIOS code as included in the Virtual Game Station code), the necessity of reverse engineering, and the value of permitting consumers to play PlayStation games on new platforms

moparisthebest, the considerable risk, with precedents, of being sued is encumbarance alone ✏

and again you have that with *everything*

Sega and Accolade imply that all this happened in a different epoch, long before digital copyright lobbying was a thing

observe my edit

those 2 are 1992 and 2000 respectively

And then the DMCA happened

> The ECPA, sections 18 U.S.C. 2510 and following, prohibit interception of electronic communications flowing over a network. Because packets are communications, network packet inspection may violate ECPA.

well that one is interesting

moparisthebest: I expect none of the implementations that resulted from the reverse engineering contained programming code that was part of the original product, but re-implementations of API's etc. If we want to make an own implementation of the SignalProtocol, we still have to literally copy the key into our code. That would be the suable infringement.

"intermediate copying" seems to protect you there, going from the above court cases

ie "I got it from that PDF your honor"

do we need to fork a new xsf-legal@muc.xmpp.org room?

jonas’: :-D

I can keep that one going!

ideally we never discuss legalities instead :)

I'll sue you if you never discuss legalities!

touche

This discussion has already burned a very significant amount of resources from all of us, and we are essentially in agreement to disagree.

moparisthebest: "intermediate copying" is as far as I understand it: making a copy to reverse engineer, decompile etc. Not copying the original code into a new product.

So could we please stop explaining copyright, trademarks and the legal risks of life and move on?

I'd like to first agree that the XSF should never explain or evaluate them, that was the intent behind my PR

Ge0rG: I think it is time indeed to let the official decision making process resolve the issues raised

moparisthebest: I'm speaking *especially* to you!

seconding Ge0rG

if this was an IRC channel, the last two days would’ve caused massive spikes in my biboumi-database-backup-size-increment-graph

If I were paid by the M.A.T.R.I.X foundation to grind the XSF to a halt, this is exactly what I would do

moparisthebest: I think we need an official decision about it, it is a valid discussion but we won't resolve it here. Agree to differ I would see...

Ge0rG: LOL! I'm just investigating how to grind them to an halt. This would be a mighty good approach!

Ge0rG, are you saying I could get paid for this? >:)

I'm not trying to cause problems, I clearly disagree with a few of you on what one of the objectives mean, and I'd like to get it cleared up officially, that's all

moparisthebest, in all honesty, from my perspective, if you don’t want to cause problems, let the topic rest until the next board meeting

because you *are* causing problems

even if it’s only me starting to actively ignore this room because it’s eating too much mental capacity for very little gain

I just responded to a question about it is all

you are of course free to /ignore or part the room, if this room isn't for discussing XSF policy I don't know what is

moparisthebest, I’m not saying this is the wrong venue, I’m saying this is the wrong time

we'll have to agree to disagree on that one too I'm afraid

moparisthebest: ignoring or leaving is very hard to pull off for a Council member

jonas’: a bit in defense of moparisthebest: I did flame up the discussion...

moparisthebest, board will decide on XEP-0001. the board meeting is the best time to argue your case

if you find that board disagrees with you, and you want to pursue this further, you can start a member vote

but that only makes sense after the board meeting

this was made clear last week already

I was just responding to winfried, in the appropriate venue

moparisthebest, I get that

and I’m not arguing that

Now that everything is clarified, we can move on

sure agreed

what Ge0rG says ✏

I know you folks were joking about grinding MATRIX to a halt, but IMHO that kind of talk is disrespectful and unproductive.

stpeter, good point

agreed, I know what I needed to know, I have made up my mind and for me it is time to follow this up in other channels

stpeter: agreed, and my apologies for that, MATRIX deserves our respect and I think it would be good to cooperate.

> jonas’> moparisthebest, in all honesty, from my perspective, if you don’t want to cause problems, let the topic rest until the next board meeting tbh I would have liked a discussion on list about this, on members@. I do think discussion is good. Decision without any context is less good. (all board members may be somewhat aware of the topic, even though I haven't seen Seve for a while, but members are not especially)

So telling somebody "please don't talk about this until a decision is made" is not a solution to me

Especially when other people bring the topic again in the room

there are already 2 comments on the github issue, I planned on making 1 more there tonight

github is not the venue for that though..

unless you want to start a members@ mail and I'll reply, or something

We have lists for that

that'd be great

if we start a list it'll just make the github convo get lost though?

I don't really care, you tell me what to do :D

It should never have been

can't change the past :)

You can quote from there I guess. I don't think people will hold a grudge