XSF Discussion - 2018-03-27

I haven't read exactly but last I had heard that was out

?

hello

?

?

Williams W, hi

?

GDPR thing in 10min

(y)

winfried: do you happen to be using an old Gajim version?

.

Ge0rG: nope, Psi+

can we discuss the time frame for this meeting real quick?

because of my (y)

I allocated an hour, would be happy with less too, more would be an issue.

yeah, we should attemt to get through this quickly, I'm 2hr over the time budget already.

good, I will aim for a close at 13:15 at max

(CEST)

```

我想知道一个问题，tor加密下这样的对话被破解的几率有没有%0.1？

pep.: are you there?

.

!

nice aditions from peter btw

yeah

I will try to setup a wiki page today

(beside my other work)

I'll continue with the minutes

pep., will you be taking minutes again? :)

thanks :)

great!

think it is best to discuss federation right away now

ok

Q1) 1. What consequences does the GDPR has for the Jabber network? 2. .. Jabber server operators? 3. .. what can/should do the XSF with that? Q2) What consequences does the GDPR has for the XSF running Jabber server? Q3) What consequences does the GDPR has for the work processes of the XSF itself (membership, voting, wiki etc)?

I think we didn't cover d-f of Q1.1 yet?

d-f?

pep.: from yesterday's list of aspects

I'd suggest (and I don't really want to get involved in this) that Q2 and Q3 are much more urgently important for the XSF than Q1.

Both of them depend on Q1

yep

Well, Q2 at least ✏

Ge0rG: what is on your list about Q1.1?

a is it in the GDPR jurisdiction, what data is b what data is processed c what processing is done d what ground does the processing have e possible consequences

Maybe there was no f.

no f

no f

we didn't fully cover grounds for c2s, true

I'd like to cover the grounds before moving on with the other Qs

Ge0rG: good

the potential consequences are vague at best anyway.

vaguely scary.

Ge0rG: Yes, it is the GDPR ;-)

I'd argue that if the user sends content via our server, they are giving implicit consent for us to process it.

Ge0rG, I’m so sure this is false.

the user could expect e.g. the server to forward it, but not to store it in MAM

jonasw: I'd argue that either Art 6 §1 or §2 apply.

or store it for less time

no, way. §1 a or b.

consent needs to be explicit

(b) may very well apply

I would vote for 6.1b

but that is overridden by 9.1

and after Peters comments I think that 9.1 very much applies to messages.

jonasw: I'm not sure about that.

maybe this is actually something to ask a lawyer about

okay, so maybe let’s write that down as something somebody should definitely consult a lawyer on.

ha

hmm, I don't see how 9.1 fits in that. I'll add a TODO

LQ1: does 9.1 automatically apply to all (not e2ee encrypted) user-sent content, or only if we are analyzing it for profiling/other purposes?

pep., in my mind, most of the GDPR handles general personal data, and 9.1 adds overrides for a certain type of personal data and prohibits all use except that outlined in 9.2

look at 9.2e...

hmmm, but the xmpp server(operator) is third party...

winfried, I’d argue that sending a message to another user is not "making it public" ✏

pep., can you note this as subject for further consulting?

hmm, let me see if I get this

what is "this" in your sentence

LQ1?

Ah, yes it's added already ✏

jonasw: lawyer-question

This is for Q1.1.a then?

Ge0rG, I am aware.

Ge0rG, I made a suggestion for what winfried might be talking about :)

:)

jonasw: ah, that wasn't clear to me. sorry

Next?

Ok: art 6.1 is explicit permission, art 6.2 is implicit permission. Article 9.1 overrides article 6 and sets its grounds in article 9.2. So if the messages are of the categories in 9.1, then we must go for explicit permission from 9.2a, otherwise we can do 6.2

we need to cover d) for all data types

Ge0rG: exact

server logs are the easiest thing.

we have those under R49

so the question for a lawyer is: are message bodies 9.1 or not?

winfried, yes.

Ge0rG: yes, agree with logs

if we consider the usage of an XMPP server as a contract between the user and the server operator = controller, 6.1b should apply to most things

... except that it should be clearly stated what happens, right?

credentials are required, IP addresses might be argued under R49, timestamps / presence timestamps are complicated.

presence timestamps shouldn’t be 9.1 at least

presence timestamps are probably covered by user's consent when they accept a subscription

I have the feeling you’re lax with consent.

maybe it’s just me, but I think consent can’t be established without the user being informed. so unless we inform the user actively what "add a contact" means regarding metadata, we can’t talk about consent here.

I also feel that needs to be specified in EULA of some sort

jonasw: > any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her

Ge0rG, that means they understand the protocol though, right?

> informed

So XMPP clients need to show a warning in the add-contact dialog, that metadata will be published to their new contact?

possibly

Isn't that for permission according to 6.1?

I would say this needs to be specified when signing in for an account instead?

pep., that would work too

probably better

because this takes the load off clients

yes

(aside from that they need to support the EULA XEP) ✏

yes, that still needs figuring out

I think 13.1 applies here

winfried: is 13.1 in addition to asking for consent?

or is it possible to have a published data collection policy and assume implicit consent from users?

13.1 feels weird

the last

Ge0rG, [x] I have read the conditions and agree

I think i need an epub of that thing and read it on the trains

btw: all of 13 is applicable

13.4 is also interesting ;-)

winfried, right

So that means EULA should do

I think sot oo

IF we can do it under 6.2

I'd argue that we don't need explicit consent for 6.2, and if we ask for explicit consent, we can tell the user not to upload 9.1 relevant data ;)

Ge0rG, "so, hey, we’ve got an IM system here. but don’t use it for private communications."

jonasw: yes

great…

jonasw: this is clearly legalese blame shifting.

Ge0rG, I feel 9.1 applies only if we do more than storage on the data, but yeah that's LQ1, we'll see

Ge0rG, but if we ask for consent, why not ask for consent for 9.1 data, too?

pep., storage IS processing

I know

I would say: if we go for consent, we should go for consent as in 9.2, so 9.1 is covered

That's why I specified

winfried, +1

Ah, hmm

Ok so 9.1 is meh, and we should probably cover ourselves, ask for consent as well

yes

but also the risk things Peter mentioned

let me read that, one sec

specifically: > It could be argued that storing very sensitive personal information, albeit for a short time, unencrypted, visible to anyone with access to the backend server (and perhaps more), does not constitute proportional data protection measure, knowing how sensitive the information can be in some cases. It could therefore also be argued, that the processing “reveals” this information to unauthorized persons, by the way it is implemented. It could therefore be argued, that such processing is contrary to what is required by article 9.

his suggestions boil down to exactly what Ge0rG said

jonasw: yes, but at how many servers is it easy for the operator to read MAM archives or view their rosters and bookmarks?

winfried, ssh myserver; cat /var/lib/prosody/archive/**/* ✏

winfried: All, I'd assume.

similarly for bookmarks and roster

it’s trivial

Also, in any case, the hosting provider will have access to the data

yes, but that surely is covered somehow.

probably something about "processor"

We need to do encryption!11

Ge0rG, yes, that seems to be the safest course of action

jonasw: yes, controller / processor thing

e2ee everywhere

Ge0rG, even with full-drive encryption, as long as the provider has access to the virtualization software..

pep., yes.

You can do technical protection and legal protection

pep.: yes, but the checkmark is crossed.

hmm, I want to believe you

Regulatory Compliance is a complicated thing.

i wanna burn something now

jonasw: my 320p bible on the GDPR?

okay, we are not moving forward.

Ok so, where are we for d) ?

With this big passage about 9.1 and consent

we have LQ1

pep.: somewhere between 6.1a, 6.1b and 9.2

and the question of privacy by design of storage at the server

I'll ask my local GDPR expert as well, and maybe Peter can shed some light as well

winfried: that's a technical question though.

Ge0rG, 9.2a specifically?

pep.: "explicit consent"

yes

Ge0rG: but it may be a consequence that technical measure need to be taken :-(

I’m pretty sure that we’ll need to take technical measures.

we need to take technical measures anyway.

even for 6.1a/b

Ge0rG: depending on the risk assesment, but looking at ubbers practices, yes...

winfried: the exact amount of technical measures is subject to discussion.

Ge0rG: yes

winfried: I think we can't cover that here.

So I suggest we skip over "consequences" and follow to the next questions

Or maybe we look at federation now

Ge0rG: not here, not now.

Ge0rG: we have got 20 minutes left, and need some time for discussing next steps/next appointments

so, lets say 10 minutes federation?

winfried: +1

we need to differentiate whether the other server is under GDPR as well or not.

Ge0rG: yes and wether the server is making secondary use of the data or not

I'm sure it is, but how

By sending a message to somebody, a user clearly wants us to deliver that message to somebody.

I somehow managed to kill my poezio

Ge0rG, aren’t all servers under GPDR potentially?

jonasw, I'm sure I can do that blindfolded

Ge0rG, because they might receive data from entities from the EU

9.1 data even (if messages fall in that category)

So when we are the sending server, we just follow what the user asked for and we don't need to ensure the receiving server is GDPR compliant.

jonasw: they can block federation with the EU ;)

my point is: our user gave us that message with the explicit request to deliver it to some other entity.

that's what we do (plus local archive storage), and that's where our responsibility ends

Ge0rG, delivery is a thing, processing on the other side is another. Maybe we should look into transfer regulations?

Ge0rG, but does the user also consent to have their message stored by the other entity?

I think the line of reasoning is:

- transfer to an other controller is one possible processings to

- it can be covered by the same concent as the other processings (LQ1)

jonasw: I think that the receiving user giving consent is sufficient.

Ge0rG, I’d like to have that settled properly, though

- EXCEPT when the other server is making secondary use of the data (then at least 6.2 can't apply anymore)

jonasw: the sender indicated that they want the message delivered

Ge0rG, given that sharing phone contact info wiht WA is illegal in DE, I imagine that things might be worse with 9.1 data being stored without "proportional means of protection"

jonasw: yes, that is the other issue: jurisdiction

Ge0rG, in the WA case, the victim gave their phone number to the offender, which forwarded it to WA.

I think this is a very similar case.

but with more sensitive data

but IANAL

jonasw: I don't think it's the same.

why not?

I think we need LQ2 here

jonasw: in this case, the victim sends the content to the offender via the evil server.

I wonder how SMS/MMS processing is legally protected

Ge0rG, I had the same thought.

but probably that’s not an issue because they don’t store data for that long

only as long as needed to deliver

Ge0rG:SMS/MMS seperate telecom laws

which is reasonable or something

jonasw, sure but then processing is done on the other side

Ge0rG, email would be more interesting

winfried: how are we different from them? ;)

okay, I don't want to be required to do LE

I agree with Ge0rG it's pretty similar

email is surely very similar, but I can't find any info on email GDPR short of email marketing

Can we try and ask big providers see how they deal with it

could probably read googles new privacy policy?

Anybody knows one somewhat open to questions/collaboration?

Right

I feel we need to structure this part of the discussen better next time... but don't know how yet

Basically lots of thing here will rely on user consent

But to what extent can we use it we don't seem to agree

Or who needs to ask for it

but LQ2 may be: can (implicit) consent also apply to transfer to other controller by addres

(needs a bit better formulation)

I think that we can apply 6.1f ("processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party") for federation

winfried, what do you mean with "by address"?

the third party is the remote user, and their interest is to be able to communicate

https://www.theregister.co.uk/2018/03/27/open_source_takes_on_facebook/

that should cover storage and delivery, but not profiling

when using @other.domain (xmpp & e-mail)

Ge0rG, maybe chapter 5 applies?

Ge0rG: no, I think that article is meant for other cases

in the end, the other service is a "third party"

Chapter 5 applies, and that is also ..... lets say, interesting

Where is chapter 5 again?

Ah

got it

art 44-50

pep., you might want to bookmark this: https://gdpr-info.eu

Yes I think that falls under this

jonasw, yeah I have it opened

So I propose we all study chapter 5 for next time? :P

And we can sum up here

5min to go

pep.: +1 ;-)

from a quick glimpse, it’s not directly applicable to federation between two entities within GDPR jurisdiction

but yeah

jonasw: yes, but federation is not limited to GDPR jurisdiction....

so for next, I won’t be available until thursday next week (5th of April) aside from best-effort

Date of next?

I suggest that we select a few dates from that thursday to the following monday and post them to the list

maybe Peter can join at one of them

does anyone know his timezone?

jonasw: +1

https://www.gdpreu.org/the-regulation/key-concepts/legitimate-interest/ is interesting here, scroll down to "Recital 47"

jonasw, no idea about his tz

jonasw, let's say date of next: 5th April, 12:15CEST, and also ask on the ML

I can’t make that specific time on that thursday

at least I can’t guarantee that

13:00CEST would probably work

works for me

but if we assume that peter is more US based, later might be better

but yeah

probably best to post that as a suggestion to the list and ask for suggestions if anyone wants to join

I would say decide of a date now, that we can move if we all agree. In the meantime we have a date.

on the 5th I have a meeting from 12:15 to 13:15 with appr. 1,5 hour offline time before and after

is Apr. 6th ok then?

I can probably make 13:15 on apr. 6th

jonasw: #meetoo

Ok for me

danger

Ge0rG, ^

I have no other appointments on 5th/6th, so whatever works

Ok, Apr. 6th 13:15CEST

*bang*

\o/

saved

thanks again guys!

I wonder how this plays with the GDPR:

https://www.csoonline.com/article/3264658/privacy/microsoft-to-ban-offensive-language-from-skype-xbox-office-and-other-services.html

jonasw, "EDIT: Except for EU citizen :-°"

hah

jonasw, what article was peter referring to again? I cna't seem to find it ("proportional means of protection")

Ah, he says article 9, and "revealing"

hmm, ok that's why LQ1 then.

That doesn't explain the part of our discussion about encryption

pep.: encryption is one of the mechanisms mandated to protect user data

I guess that's art 35

https://mastodon.social/@Gargron/99730137003463631 they don't seem worried

Anybody what goes into that audit log? http://dougbelshaw.com/blog/2018/01/31/social-network/

(grep GDPR)

I wonder how far a non-EU citizen/service is required to go to ensure non-EU people use their service?

is the GDPR only enforceable if an EU citizen sues you?

moparisthebest, I wish I knew at least that

anybody knows*

if so, then everyone can just put up notices like "EU citizens are forbidden from using this service"

because they wouldn't have standing to sue you about GDPR stuff in court, because they violated your terms?

at least, I think

I have no idea

I have a feeling I should prepend IANAL to any comment I make during our sessions

pep., easy. /nick pep.> IANAL:

:D

yea until we get a single lawyer in here ever, maybe a server plugin should do it automatically?

jonasw, will do next time

aww

the MUC won’t let you

moparisthebest, yeah, no

pff

that might be a solution for you USians

for certain definitions of "solution"

or, wait, you aren’t talking about the "no EU citizens" thing anymore?

moparisthebest: I think it's about targeting. If you have a european domain, support languages spoken here, etc.

I mean't a server plugin should prepend IANAL to what everyone says :)

Ge0rG, "support languages spoken here". english?

what languages *aren't* spoken in EU ?

I feel like that'd be the shorter list

:P

:D

You could state "Here we speak only en_US"

or maybe you limit the character set to ASCII

that would de-facto ban most of the EU

moparisthebest: switch to IBM EBCDIC

to ban the whole world?

jonasw: there is no world beyond the US of A

I forogt

I, for one, am proud to be an EU citizen, and to finally have legal remediation against Silicon Valley sucking up and reselling all my private data.

except turns out it's the same kind of legal protection you had before

that is, to just not use the services

moparisthebest: I'm not using Facebook. I'm not using WhatsApp. And still they have data about me.

Ge0rG, +1

not data you didn't share somehow, presumably

moparisthebest, but did I share it intentionally?

it's the #1 rule of the internet, put it on the internet, it's there forever

moparisthebest, I didn’t put my phone number on the internet.

yet, whatsapp has it most likely

no laws are going to change that

moparisthebest: oh yes, our laws will change that.

yea the law changes things, now you can't use open federated services

good work

moparisthebest: but it depends on what you mean with "put it on the internet" - make it public? use some internet service? contact your friends?

related: https://twitter.com/iamdylancurran/status/977559925680467968

BTW, that the BigCorps are required to provide all the data they store about you is also based on EU regulations

Ok so I have https://cryptpad.fr/code/#/1/edit/eitMC7lM6yOU4kFtNf1Nag/gvYO8K5YdRtKg-b7hNLd7mEz/ Ge0rG jonasw winfried, can you have a quick look

f*ck!

I hate that noscript b ug

pfew, I was in luck. but still

pep., looks good to me

Most of what we talked about today goes into Q1.1d

There's this "Server logs: r49" line that's kind of sitting alone there, the rest is about consent :P

pep.: nice!

jonasw, also I'd be inclined to say 9.1 only applies to "processing revealing [such information]", as peter suggests? But IANAL

pep., peter argues that processing which stores the data in plaintext may reveal it to operators

Ah, in that sense

also, I think the recital is clear that the *data* reveals the information, not the processing

Well, so full-disk encryption is besides the point right?

the legal text is ambiguous IMO

in both translations oddly enough

(it could be either the processing or the data which reveals info, in both en and de)

Because operators will most likely always have access to this information, except in the e2ee case

pep., exactly.

Even in the e2ee case really, it's still possible, as not many people actually checks

That would be making significant effort though, for the operator, and could be caught as well

that would require an additional action you normally wouldn’t do though

Security goes as far as one is wiling to apply it (and even then..)

So I'm tempted to remove the full-disk encryption part in the minutes, and add a bit about e2ee

(Since it was my misunderstanding)

pep.: "encryption" is just a control you "need" to checkmark.

I think tehre was talk about both

Ge0rG, what encryption, where

jonasw, yeah, right

pep.: a secure service will deploy a combination of disk encryption, stream encryption, user data encryption and e2ee

pep., in line 64, it was definitely about FDE

pep., maybe add a note about "ubiquitous E2EE would save us from 9.1"

I wish

Ge0rG, right

jonasw, here, done

thanks

Ok, sending that

thank you for that already :)

Wow, the mails take quite some time to arrive

It takes a while for all the racial profiling the server needs to do before sending them out.

I see

Makes sense

is there a reason the members mailing list is not linked from here: https://xmpp.org/community/mailing-lists.html

moparisthebest, possibly because it’s only for members

I was trying to give a link to the GDPR discussion to someone and had to manually construct it

I don’t think you can subcsribe as non-member.

jonasw, if that's true it's incorrectly configured to be public https://mail.jabber.org/pipermail/members/2018-March/thread.html

https://mail.jabber.org/mailman/listinfo

moparisthebest, maybe

(I clicked on 'standards' then changed 'standards' in the url to 'members')

iteam? (cc @ Kev, intosi) ^

it's listed here

I personally don't see a reason for it to be private, I'd just like to see it listed next to the rest :)

What's the problem here? The list should be invite-only, public archives.

Kev, then there’s no problem :)

except it's not listed on https://xmpp.org/community/mailing-lists.html

Kev, except htat maybe it should be moderated-by-default and free to subscribe, if the archives are public anyways.

I see no benefit to that.

Kev, ease of use

It's easy to use for members, and that's all that matters here.

I'm not even sure what the ML is *for*

Kev, arguably, that discussion is interesting for non-members too.

but I don’t think that standards@ would be the right venue

what would be the most appropriate list then?

operators probably

Yeah I don't think either. Maybe _only_ operators, would be best

I'd have thought if this is an XSF activity, members is appropriate, with CC to operators anything that will interest them.

yea I was just linking other people for some feedback

and it was super hard to find a link that I assumed would be on the mailing lists page that I assumed would list all mailing lists :)

Kev, intosi: it will be nice to have a ML for jabber.org service and updates on https://www.jabber.org/notices.html about problems like previously

http://mail.jabber.org/mailman/listinfo/juser <-- not clear if it is for jabber.org service

IETF folks that also idle here: are you aware of any SASL mechanisms similar to SCRAM (active or in development) that use Argon2 instead of PBKDF.2? I was going to use Argon2 on some passwords since it's the current OWASP recommendation, but there's a chance I'll want to use the same credentials with an XMPP server later (though not in a way that requires wide support, so it doesn't matter if it's still in draft or something).

I assume a quick search would have revealed it if it was already a thing, but I figured there might be an I-D which tend to be harder to find.

Not sure if I qualify, but I'm pretty sure you can swap out PBKDF2 for some other equivalent construct.

In SCRAM you mean? I think it allows you to swap out the hash used in the HMAC, but not the key derivation function. Let me double check, it would be nice if I was mistaken.

I do believe that the general construct still makes sense with a different key derivation function.

Oh yah, it does, but I'm hesitant to do something completely non-standard

yeah, but it’s not standardised

SamWhited, cp scram-rfc.xml argon-scram-rfc.xml; sed -i s/pbkdf2/argon2/g argon-scram-rfc.xml; submitrfc argon-scram-rfc.xml? ;-)

jonasw: what and where are those XML files located?

"What are those XML files and where are the located", that is. That sentence got away from me.

They… *facepalm* I really can't type.

Yeah, where are those?

I only recently discovered that there actually is a big XML file with RFC information… the IETF has even worse search engine rankings and visibility problems than we do, I'm pretty convinced.

But it's not detailed and doesn't include I-Ds, as far as I know.

https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml#sasl-mechanisms-1

ooh that's a good idea, thanks. Although I don't think that lists any I-Ds that might be floating around out there; still, good starting place!

hey, ALPN ids are listed now https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

kind of a strange way to word the protocol, but I guess it's correct enough?

XMPP jabber:client namespace

XMPP jabber:server namespace

wonder why some IDs are rather long and some others short

SamWhited: There's http://www.ietf.org/download/id-index.txt but it's huuuuuuuuuuuuuuge

oh that's how it's listed in the XEP too, did I do that? hehe

And maybe the kitten wg?

ah..it's the idrect textual representation

https://tools.ietf.org/wg/sasl/ https://tools.ietf.org/wg/kitten/

https://bpaste.net/show/138cf21c832d irccloud.com just updated their term apparently, some IRC web client. I feel this will be relevant to movim instance admins, edhelas

That's interesting, they claim to be a data processor.

yeah I noticed as well

Syndace, how is your omemo lib writing going

lovetox, I spent the last days trying to get a simple client up and running that echoes OMEMO messages, with partial success. Debugging is extremely annoying as the OMEMO of the official clients is a mess. I once accidantly published some wrong data to the pep node and the OMEMO plugin for Gajim completely died and remained unusable till now. Trying to send messages just fills my terminal with stack traces. Conversations sends some weird empty message after the initial handshake. I thought I understood why it sends that message but then I found that Conversations 2.0 sends a different, even weirder message... The small success: If my handmade client does the active handshake, the echoing works with Conversations as expected, so the crypto should be fine :) I'm at the point where I'd probably need to dig into the code of conversations and gajim to understand the problem, but I really really really don't want to, got a lot of work atm. But thank you for asking, I just remembered that my goal is to provide the crypto and not to provide a working client. Tomorrow I'll clean up a last few things and release it, so you can try your luck with other clients :D

Neustradamus: Hi! I'm fine, thanks :D

im the developer of the omemo plugin

in gajim

so if you need help add me lovetox@conversations.im

also if you release your work i can adapt it to gajim, and then you dont have to put work into the whole client and xmpp protocol stuff

Syndace, delegate! :)

less work for you

yes, its really better you just release the work, and let client devs implement it

afterwards you can use the client to debug encryption related stuff

im offering to do this as soon as you release it

One question about the licensing stuff: I already have MIT checked into the repo currently. Now, I have to release GPL as we discussed recently. If I just commit the new license, then someone can clone an earlier commit and get the earlier code including the MIT file. Is that a problem?

Wow thank you!

hmm, I guess they can fork an ealier version of the work, though they would be liable? Maybe you can explain the reasons you're changing to GPL somewhere

It's always dangerous to change licenses in midstream...

git-filter-branch!

SamWhited, it was merely a convoluted way of saying "take the SCRAM rfc and do the same for argon2" sorry I got your hopes up (cc @ Zash)

pep.: Thing is, I'm not just "changing" the license because I want to but the first license was never the correct one and I could get sued if I don't publish as GPL. git filter branch? Those dark areas of git that I try to avoid :D

Syndace, git filter-branch or something equivalent is your only way.

alternatively, you can squash the history

why are you bound to GPL though?

Are you, really?

Probably should take what us non-lawyers say with a truckload of salt

Syndace, clone your repo somewhere for backup

squash everything into one inital commit before releasing

upload finished

squash is meh :/

Zash, I am bound to GPL. Until we define our own wireformat.

Syndace, what

source for that?

jonasw, for what? That I'm bound to GPL?

yeah

I guess I could create a fresh repo with just the newest commit and release that one

that doesn’t make sense to me

someone told him here

because he looked into signal source for the wire format

jonasw, to be abled to talk to libsignal I needed to copy a few params from theit code

I don't think there is any way that is not GPL

isn’t there a specification aside from that code?

For large parts, yes

anyways, heading out.

But the specification says for example: "Set this parametet to an application specific ASCII string"

Which I had to copy from libsignal because it is not defined anywhere

But then again, it's no problem to switch to MIT once we define our own parameters

Not really sure what's frightening about GPL tbh

Probably a bit of FUD on account of Moxie & co being weird with reimplementation of signalprotocol

I meant, why not just stick to GPL

pep.: GPL is fine for now but I personally don't like the philosophy to force open sourcers to use some license.

Depends on your end goal

pep., because not every client can ship gpl code

there is a huge discussion about this

on the list

lovetox, that can be distributed via another channel? You already have plugins for gajim for example

pep.: I was on why GPL, not why not.

But tbh if it were me I'd just put the client under GPL

poezio for example is not under GPL if i remember correctly

zlib indeed

also jitsi i think

yeah but we also have plugins. There is no case for now for external plugins though, since all are commited in the source

smacks lib i think is also not

But it would be doable