XSF Discussion - 2017-09-13

That was my first thought

good morning :)

edhelas, wait what, pizzas?

jonasw, yup, but you have to finish MIX before :(

damn

I hope MIX doesn’t become our Duke Nukem Forever

Haha :D

even though I’m lucky that I don’t have contact to the people from ten years ago to whom I jokefully made promises based on "when Duke Nukem Forever gets released"

haha, I remember the bets on which comes first - DNF, PS3 or DM8000 (a highly anticipated Linux-driven HDTV set-top-box)

which of those lost?

the release order was PS3 -> DM8000 -> DNF

moparisthebest, Guus: yes, an article about this said this too, but it's about the 'health of a community". but what do you think. would this be interesting for XMPP?

emxp: i have not looked closely enough to formulate an opinion.

Im gonna search for an article in english about it

the deadline to submit a talk to T-DOSE (in NL) is at the end of the month

edhelas, I hope we can get recordings :)

the on_sub_and_presence config for PEP start to be a massive souce of stanza spam on login on my side

I'm wondering if we could not put it by default and use MAM to handle that properly ?

basically change that part in the XEP

edhelas: why you don't filter it (removing +notify) ?

> A server MAY include messages of type 'headline', but this is not generally suggested. to > A server MUST include messages of type 'headline', but this is not generally suggested.

goffi, because I still want to be notified when an item is pushed/changed

right, I was thinking about explicit subscription, but it doesn't change anything about on_sub_and_presence

edhelas: were do you find "A server MAY include messages of type 'headline', but this is not generally suggested." ? do you have a link ?

goffi: https://xmpp.org/extensions/xep-0313.html#sect-idm139061241577408

oh in MAM, OK

Very XMPP-like. "It might work this way but maybe not, you never know!"

by puting headlines in MAM we could simply forget "on_sub_and_presence" and set pubsub#send_last_published_item to "never"

edhelas: headline are not supposed to be stored offline, I would change it for MUST NOT

The question is whether that rule makes sense.

and pubsub notifications should not be headline IMHO

And if it does, maybe we want to find a different solution to do what edhelas suggests.

I think the basic idea makes a lot of sense.

at least not by default

Well this forces clients to do MAM

The obvious problem is that this won't work for clients that don't support MAM.

Yes.

And MAM is a lot harder than just parsing incoming notifications

This doesn't only effect legacy clients

And MAM is experimental

well we can still put headlines in MAM and progressively deprecate that in Pubsub

again, headline should not be stored offline

daniel: Because you might not fetch all history since your last session from MAM?

I see the issues. But I totally agree that resending unmodified PEP nodes on each and every login is stupid and can become a scalability issue.

Holger: well I'm thinking about someone implementing a new client from scratch wanting to support avatars or omemo and they would also have to implement mam from the very beginning

It will just make it more complicated to write clients

that's a different broader topic, but we need to start advancing XEPs

daniel, We can have both, still have on_sub_and_presence and MAM. But knowing that the server handle the headlines, I'd just drop the incoming PEP stanzas and handle only the MAM ones.

moparisthebest: yes

xeps everyone has to implement for 'modern' chat experiences currently range from experimental to deferred and everything in between

even 'draft' doesn't sound that great, and, apparantly, nothing EVER gets moved to final :)

If we put stanzas in MAM we'll also put them in offline storage so testing single-client usage should work without depending on MAM. Multi-client UX is bad without MAM anyway.

And there was some backlash when I tried to add more features to pep from people who want to keep pep really simple.

But I see how we don't want to require clients to always retrieve *all* MAM history.

I imagine those people won't be happy when we depend pep on mam

I don’t have a strong opinion on your other pep suggestions, but depending pep on mam sounds horrifying.

but ... it kind of makes sense :/

and MAM is part of the 2017 compliance suites

What is it all about?

well this is about finding links and coherence between the existing XEPs

I don't see the issue, 1) on_sub_and_presence is the default but can be disabled, 2) pubsub notification should be normal messages, not headline, so they will be in MAM 3) and again headline should not be stored offline

edhelas, sure, but avatars are Core Client, MAM is Advanced Client

Weren't there something where you'd include a timestamp of your last notification and things would avoid sending notifications unless they have newer data

Zash: pubsub since ?

XEP-0312

But in general; the amount of bootstrapping and the resulting traffic I have to do on a full connect is enormous

Nyco already talked about this in a summit, but no action has been taken.

daniel, +1

and you can tell even in conversations which tries to hide it (if you disconnect an account, then toggle it back on, the 'Connecting...' phase takes FOREVER)

for my account, I have ~5/6MB to download from the server

goffi: type=normal will only go into MAM if it has a body, according to the rules.

Holger: oh I see, then this should be changed. But keeping headline is really bad idea IMO

goffi: And I think it's desirable to agree on a single way for syncing PEP items. If one client depends on on_sub_and_presence and another one disables it, that won't help UX.

Holger: the fact is that it can be disabled already now

goffi: about the amount of data on connect? That was the summit two years ago even

daniel: yes

aaand we’re back to persistent/transient messages :)

goffi: I was not arguing it can't :-) I was wondering about what's desirable.

Yes. I would really like to have a recursive disco caps hash thing that also hashes items

Holger: I generaly like the fact that you can adapt to your special case, but the trick is as it is done now, we can't be sure that we have the desired bahaviour without checking node config

daniel, just the list of disco items or whole pubsub items?

Or rewrite Conversations to hold state across restarts and just resume all the time

jonasw: disco items mainly

just disco items isn’t difficult

we could add this to XEP-0390

(and their caps hashes of course)

daniel, I’m not sure how that helps though

I'm not sure it would help to hash items, it's working well with feature because it's a quite static data, but items can change a lot and often (think about MUC rooms)

So I don't have to refetch all items' features on every connection

what kind of items?

jonasw: when trying to figure out where the conference server or http upload server is

goffi: Our specs can be adapted to many use cases, but we're sometimes bad at specifying a single solution for a given use case, which results in bad interop. This would be another such case, IMO.

daniel, ah, right

daniel, do servers really have that many items that it matters?

jonasw: yes

Holger: I agree

interesting, examples please?

I wonder what’d be in there aside of a conference and an upload domain maybe

3 or 4 at least. Http upload, conference, pubsub

Echo sometimes

Proxy65

gateways

Gateways on old and stupid servers 😊

daniel, I wonder whether we could expand the disco#items response to include hashes if servers support it

that is a reasonable extension, and perfectly backwards compatbile

jonasw: yes I should probably raise this on the list again

I’m all in for adding this to XEP-0390 if nobody finds a notable issues with it.

Two step process. Include the hashes in the items response. And then do a hash over the items

*the items hashes

I have a few ideas regarding Syntax but I'm on my phone right now. Can type them out tomorrow or so for the list

daniel, I was thinking <item ...><caps xmlns="..."><hash>...</hash>...</caps></item>

so regarding my proposal ?

There were also concerns from server items regarding how the server should know the caps hash of the item

(I think I brought this up before)

*from server developers

Thank God mailman offers a convenient way to search the archive and Flows offer to setup discord way rejected

Discourse even :-)

daniel: why "on old and stupid servers" ?

goffi: because 2005 just called and wants their broken transports into networks nobody uses back

https://xmpp.org/extensions/xep-0312.html , looks like MAM to me

A call our friends at matrix never received by the way

daniel: there are gateways for IRC, mattermost, Skype, etc. I would not say nobody use those

gateways that are implementing 20% of the features, buggy, breaks after weeks/months

maybe except for IRC

thats for bad gateways

because it's a quite stable protocol

Is there any spec to resend message by a server when destinee server is offline? Something like SMTP which retry after a delay?

goffi: one could use 0198 on s2s links

GeOrG: that works for short outage in existing server, but I'm thinking more about first message to offline server.

goffi: it might be a better UX to reject the message immediately. How are you supposed to know if that server exists at all?

you're not, but would be nice to try for a little while like email.

Some servers do

goffi, I think trying for a while isn’t a good idea for IM

(for certain definitions of "while")

a few minutes may be ok

That's great when it's spam they are trying to send, and you end up with one billion connection attempts

Zash: same for email, and it works quite OK

Email isn't Instant Messaging

But Jabber is the Email of IM!

goffi: I'm about to implement just that. I think it's horrible that we don't survive remote server reboots.

goffi: But I don't think we need any spec for that.

isn't "survive" very relative?

I think it would be a better UX, in a federated IM network, to have a "send again" button on failed messages.

Fail early, fail often!

Users love errors.

Holger: yeah, silent failure is much better.

Did I suggest that?

Of course you return an error if retrying fails for n minutes.

I think that having N>1 wouldn't be wise.

Ge0rG: IIRC I can submit a message from Yaxim while I'm offline? Why don't you return an error?

goffi: servers would have a hard time keeping track of order requirements. so this is probably a responsibility of clients.

Ge0rG: Why not? Because INSTANT?

Ge0rG: Why do we accept pending 0198 sessions for N minutes where N>1 then?

Holger: because instant, yes.

Holger: yaxim has a clear UI indication for offline messages.

just make sure you have appropriate backoff set up, otherwise a server gets DOS'd, then good servers trying to reconnect and send messages end up DDOS'ing it

Holger: do you have the same on s2s?

Holger: the issue is as a client I want to know if I can rely on this behaviour or not

Ge0rG: No. Just like I don't for the last hop from the recipient's server to the recipient's client.

goffi: You should rely on the message either being delivered or an error being bounced, IMO.

fippo: order would be hard to keep indeed

Holger: but that server at least knows if the client exists.

Ge0rG: XMPP is not only about instant messaging

Ge0rG, Holger, you could return a type="continue" error while retrying :)

Ge0rG: So we must return an error immediately because you can't wait 5 minutes for the error if you sent a message to a non-existent contact? Seriously?

jonasw: a what?

Ge0rG, https://tools.ietf.org/html/rfc6120#section-8.3.2

Oh god. I wonder if there are any clients implementing that.

Might be a good idea.

Holger, write a XEP which specifies that behaviour for any intermediary and also adds an element which indicates until when delivery will be re-tried

Something like the "We're still trying to deliver your email" notifications?

Zash, yupp, but with more easily available semantics

Please hold the line!

Is there anything saying how many type=error replies you can get?

not that I recall

Except for <iq>

jonasw: what kind of stanza do you send to revert a type="continue" condition?

Ge0rG, any other?

jonasw: any other what?

any other error?

I see

hrm

things are getting interesting again

Ge0rG, maybe an opt-in is better for this type of stuff

in which case another type="continue" "error" (meh) could be sent which indicates that the delivery has continued to the next hop

we need a new error type "continued"

that requires a change to RFC 6120 ;-)

isn't this about EXTENSIBLE?

also as an email client you have no idea if your email is delivered ever, or whether you will get a delivery failure notification or not either

I think just retrying a few times instead of giving up immediately will make everyone else happy :-P

so it's a pretty bad comparison

moparisthebest: You'll get a bounce a few days later.

you *might*

it's not because email doen't do it that we can't

we have discovery for that

also we know (I think) we are only going through 2 hops max, client1 -> server1 -> server2 -> client2

email can travel through unlimited server hops, each of which can have their own policy where they just scrap your email and notify you or not

the original argument was 'email retries so we should retry too' but that's not actually the case is my only point, in reality maybe your email server retries, but you can't count on anything

Dunno whether I said that, but my main point is "users want retries to happen automagically rather than having to cope with temporary issues themselves".

moparisthebest: no, the original question was "Is there any spec to resend message by a server when destinee server is offline?", and SMTP was just given as an example

and if a server implement that, I would be able to know it with disco, so I can display it properly in UI

fair enough, I think I agree with Holger though, that there really doesn't need to be a spec, the server should optionally retry once or twice over a short time, and send back an error if unsuccesful

I was hoping for something on a long time (e.g. personal server offline for the week-end because of maintenance), on a short time a spec is probably not needed indeed.

so I send a message to someone@conversation.im and don't get an error message for a week because I missed the ending s ?

moparisthebest: no, I think more about "your message has not been delivered, we'll try to continue sending it for 2 days before giving up"

I still think a user tends to wait instead of double checking their spelling though

Holger: how many attempts do you want to make? and what exactly are you going to attempt?

Holger: I think it is valid for a server to cache a stanza and attempt all the SRVs, direct DNS entries, IPs etc before giving up, but no more than that.

what if the DNS server is being rebooted ? :)

I really think that it's better to expose an error in the first <60s and to allow the user to resend with one click.

also you really aren't supposed to do that with SRV or DNS records

yea I agree

I mean, give or take a few seconds

Ge0rG: Well I would make this configurable, but my initial idea would be to retry for 5 minutes by default, as that's a typical 0198 timeout which seems to work for most people.

we were talking about using MAM for notification before, delivery would be important there: if a notification is sent while destinee server is offline, it will not get it, and the pubsub item may be missed. This would not be the case with a pure PEP notification.

Good point.

Maybe 0312 is not a bad solution for edhelas' issue.

board meeting in 3 minutes

ralphm: nyco: Martin: MattJ: here?

Here

Here

So, the classic Bside board this week

3/?

here

3/5 but mattj, martin, and myself are a classic combo

go

ah nyco ruins it

sorrry

I can go

who's chairing this week?

nyco: its a joke

I am joking too

sorry for the misunderanding ;-)

humor subroutines confirmed

hehehe

so who's chairing this week?

I can chair, if just to break the silence...

thx

Ok, *bangs gavel in traditional fashion*

1) Roll call

here

o/

Here

Splendid

2) Minutes, volunteers?

o/

Lovely

3) Topics for decisions

Running from Trello here: https://trello.com/b/Dn6IQOu0/board-meetings

SCAM: blog post on hold POSS booth meetup in Krakow

3.1) SCAM. Where did we end up with this?

if my agenda is related to the board

The agenda comes from Trello. If it's not on Trello, it doesn't get in.

https://trello.com/c/0Flwsyqs/278-scam

I've left a lot of questions for the board

OK, lets try and rattle through them then

3.1.1) Can SCAM have a budget for things like stickers and folders?

I thought we already approved that

nope - board approved a one-time reimbursement.

what kind of budget were you thinking?

sure, how much budget?

Guus: ?

that is below 1k

maybe it would be useful to define per-purchase and per-month caps, and to require individual board approval for higher budgets?

500~1000 USD / year

sorry, I'm in a building that's being closed down, after which I've got a 2h commute - might be unresponsive.

yeah, that corresponds to our capacity, roughly

I'll have to go at :30

That seems reasonable to me, though I realise that I don't have any idea how the XSF currently stands financially

we're doing good

^ What MattJ said

Roughly $10k balance, as I recall.

I'm good with $1k/year

+1

Ditto, +1

nyco?

we vote on what?

$1k/year for SCAM

+1

Good, moving on

3.1.2)Can SCAM get access to the social media account(s) (for event announcement purposes). Notably: Twitter. The blog is accessible enough via PRs on the website project.

How is Twitter currently handled? Who else has access to it?

is there a meeting going on?

stefandxm, Yes, XSF Board.

ty, then i will back off :)

we could use tools such as HootSuite or Buffer, so that everyone has its own account/password

(back, now from a parking lot with crappy reception)

so that the SM accounts passwds are not shared

or write a twitter-xmpp bot that does the same :-P

that was a joke

I'm less interested in the how, as in the approval itself.

So, we need to find out who has access, and hook them up with Guus, agreed?

is it a board duty to approve that?

Arc: that bot would then post a dozen of russian spam messages a day, just to make a point.

nyco, In as much as it has not been devolved elsewhere.

I'd be happy to find the person(s) with access myself, btw.

SCAM should be responsible for SM accounts

Wasn't there a social media team or such before?

nyco: unsure, but topic for another meeting. SCAM is not commteam.

(yet?)

ah good point

given the time is nearly up, are we still discussing technical details or is this on-topic?

I guess commTeam could merge in SCAM

cause I’d like to have my trademark application discussed

for what it does...

nyco. please, first the questions at hand

I've been waiting for weeks on feedback

given the time limitation: your votes please?

can't you just approve that SCAM team shall get access to SM?

OK, so, we're happy for SCAM to have access to SM?

+1 for me

+1 of course, I add the SCAM should be responsible for those accounts

Arc, MattJ, votes?

+1

Martin, in the interest of time: could you quickly do the member confirmation, for the record?

Sure

should be a formality

tx

3.1.3) Does board approve Daniel Gultsch as a member of SCAM?

+1

+1

+1

MattJ?

OK, approved. Next:

3.1.4) Does board approve Nicolas Vérité as a member of the SCAM?

+1

+1 ;-)

+1

it hurts, voting for myself

Arc?

+1

OK, approved. NExt:

3.1.5) Does board approve Guus der Kinderen as the team leader of SCAM?

+1

https://wiki.xmpp.org/web/Summits_Conferences_And_Meetups_team

+1

+1

MattJ?

+1

OK, approved. Next:

3.1.6) Setting up MUC and mailinglist for SCAM

+1

+1

is it needed?

we should create stuff when it is needed, because that's one more thing to manage and maintain

I've suggested to take over the summit-ones

doing it here would we enough no ?

but could create new ones if desired

I don't have a strong preference either way.

nyco: I'd prefer the team to be addressable by people seeking assistence.

ive gtg

I see

+1

+1

OK, approved, next:

3.2) Apply for trademark sublicense for JabberCat

Relevant GitHub PR here: https://github.com/xsf/xmpp.org/pull/358

+1

+1 from me

I think a mailing list is ok (because we don't have one suitable already), but probably this MUC would suffice (and has more people active in it)

(Thank you for pushing all my questions through. The SCAM trello card can be archived now)

Sorry it took so long Guus, glad we got there in the end.

gotta go as well

MattJ: Do you have an opinion on the trademark license? Just needs your +1 to get it done.

+1

As a point of order, it looks like the Board may not be quorate anymore. Although I cannot recall its quorum rules. (Also, if ralphm is actually about that'd solve the issue).

(nyco voted on the last item, but is now gone)

Nyco did his +1 before disappeareing

And we're not quorate any more, so I guess we should disband

sorry, bye! ;-)

Yes, indeed. Just noting this might curtail the meeting.

thx all!

I'm okay with postponing my questions to next week.

sorry Ge0rG - mine are now out of the way though.

This was a very intense and productive board meeting, so thanks to everybody

Ge0rG: If you send them to the members list, I can put them in Trello so they're ready, or are they in there somewhere already?

Martin: all in trello already

Skipping 4) and 5) due to no people. And 6). 7) +1W

Done. Phew.

SPAM and trademark fees

Martin: regular folk like us can add comments to cards, but not create cards. So, if board creates cards, others can fill in the blanks (not sure if everyone knows that). Could be helpful.

Ge0rG: Righto, yup, they're in there.

Guus: Good call, dwd, can you mention that at the end of the minutes?

there might be some cards that can now be removed, by the way. I've left housekeeping comments.

Ge0rG, FWIW, I'd be rather against a SPAM team/SIG. I think it can be, and should be, conducted in an existing venue (operators?)

ok, I'm going to drive home now. Thanks again for pressing things through.

just generally curious, is there anything stopping cisco from just changing their mind and revoking the license to use jabber to the xsf and any sublicensees ?

i've a generic xml/xmpp question. about xml:lang; how is it suggested to use in iq stanzas. should the receiver respond with the same xml:lang or should if you make a "requested language" attribute have it explicitly added?

xml:lang is inherited, so you should just use whatever xml:lang they specified (probably on the stream, but maybe in the individual payload)

yes, but what about the response

ie; "i want information about xyz and i want the information in language nnn"

should that be implicitly understood by the language used in the request or should it be added in the payload as a specific attribute/request ?

It should be added in the payload or on the IQ itself if the one they sent doesn't match the stream.

XMPP is a bit odd in that there are two streams going on, one for input and one for output. xml:lang won't be shared between the two

exactly

so should i add a "requested-lang" to the payload in the iq 'get'

or should i make it implicitly / recommended that the responder uses the same lang as the request is marked

So the flow is that you decode the IQ they sent you, check the xml:lang (which is probably inherited from the input stream, but might also be set on the IQ or payload itself), then check your output encoders xml:lang (probably set on the initial stream) and if it doesn't match set xml:lang on the IQ or payload before you send it

No, the "requested lang" *is* the input's xml:lang value

yes, the second one

great

makes it easier for me :)

(someone who actually knows XML should double check me on that, but I'm pretty sure everything in the http://www.w3.org/XML/1998/namespace namespace gets inherited)

SamWhited, not sure about the namespace, but xml:lang for sure gets inherited

dwd: I don't care much where SPAM is handled, but there might be value in making it invite only

the non-response is kind of what worries me, almost as if no one here knows anything about the jabber licensing scheme ... :)

the point of xmpp for me is not to rely on the ongoing goodwill of some huge company, if we are indeed relying on the ongoing goodwill of cisco to use jabber, well, then I should just go back to google, hangouts?, or whatever it's called nowadays

moparisthebest: I don't know anything about the jabber licensing scheme, but the question also didn't make sense to me. A license *is* the thing that stops Cisco from changing their mind, no? Isn't the whole point of having a license or an agreement or whatever so that it's not just their word?

Also, it has nothing to do with using XMPP as that last thing suggests; it's just the term "Jabber".

SamWhited, the only document I ever saw was a vague promise with a big NOT A LEGAL OR BINDING DOCUMENT prefix, from jabber inc to xsf before cisco bought them

this is what I'm asking about, *is* there a license, and what does it look like, what are the terms

moparisthebest, maybe you should try to get a hold of stpeter

I think he’s most likely to have details and possibly even the related paperwork

the license might say "cisco reserves the right to terminate this license at it's whim" for instance

and that's fine, but if only stpeter has it, that's a problem too

we just need to get large enough that Cisco wouldn’t dare to because we can generate enough negative press for them by whining publicly about it :>

then if stpeter gets hit by a bus and cisco decides to revoke it (or sue everyone), then what? :P

the bus factor thing has been discussed in one of last months board meetings btw

SamWhited, true except there has been a push recently to standardize client language etc on the term 'jabber'

moparisthebest: https://xmpp.org/docs/Trademark_Enforcement_Agreement.pdf, https://xmpp.org/docs/Trademark_License_Agreement.pdf, https://xmpp.org/docs/Trademark_Letter_Of_Intent.pdf

SamWhited, nice find

See also: https://xmpp.org/about/xsf/jabber-trademark/background

ah yea all I saw before was the letter of intent

which was the first result in a Google search for "Jabber license agreement" or something to that effect.

anyone have a URL to the "Jabber Trademark Position Statement"?

ah, it’s attached to the letter of intetn

does a pubsub node should return <feature var='http://jabber.org/protocol/pubsub#publish'/> if the JID is not authorized to publish an item in that node (applies for all the other stuff in the disco#info) ?

jonasw, SamWhited do I read that wrong? https://xmpp.org/docs/Trademark_Enforcement_Agreement.pdf is expired because it's only good for 12 months from 2003 and if it terminates in any other way than transferring trademark to JSF, trademark goes back to JINC ?

I am not a lawyer and hate legal things grr

moparisthebest, that document is only about enforcement of the trademark things I think

so we probably just care about https://xmpp.org/docs/Trademark_License_Agreement.pdf now, I guess

a couple questions about that, does it change anything legally that neither Jabber Inc nor JSF are a thing anymore (former purchased by cisco, latter now XSF) ?

no, it doesn’t

with the purchase Jabber Inc merged into Cisco, which is why everybody is talking about Cisco instead of JINC now

the XSF is simply a renamer of JSF afaict, so legally the XSF has fully inherited whatever the JSF did

IANAL though

What does point 5. mean? "No Right to Assign or Sublicense" ?

I don’t know.

I wonder whether there’s a follow-up document to that enforcement thing

and lastly after we answer that about #5

cisco can terminate this within 30 days if xsf doesn't enforce something

what are the chances of the xsf being able to enforce anything ever, let alone within 30 days?

there is no lawyer on staff for sure, right?

moparisthebest, take action and enforcing are two different things

but yeah

good job, gandi. searching for jabbercat.org domain name, it suggests gibberish.cat >.>

Are you going to use jabbercat.org, jonasw?

SouL, I plan to

sounds like you should use jabber.cat instead jonasw :)

moparisthebest, gone

and cat has terms I don’t want to have to adhere to

sounds like the XSF needs to get to enforcing

oh really like what?

domain names are fair use something

moparisthebest, with .cat, you need to support the catalan culture/language in some way

people apparently simply put a google-translate-ed version of their page up

ah ok, well, you'd support instant messaging in catalan right? :)

jonasw, are domain names fair use? because https://xmpp.org/about/xsf/jabber-trademark/usage-guidelines.html 1.3 has a whole section about when they are not allowed

yeah, it describes what falls under "fair use" and what doesn’t ;)

jonasw, as I said, if you want to use .cat I can really help with that! And they don't really care, so...

jabber.cat is also a jabber service apparently: https://jabber.cat/

so I don’t want to fight them :)

jonasw, did you notice the first word haha, funny

Això

hm?

isn't that your library name-ish?

Això means "this" :)

hm, not really (aioxmpp vs Això)

well, "that"

close

shift it around a little aixòmpp and now you can register a .cat, no one will even notice

vanitasvitae, firefox refuses to connect to geekplace.eu (you linked that in your protoxep thread on standards@) with HTTPS due to SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED

Hm, thats Flows site.

my firefox is fine

I wanted to get xmpp.cat but it was taken already

maybe those are my facist cipher settings ... I think I disabled RC4 or something

see what ssllabs says shortly, it's scanning

ah it's using CAcert

ah, maybe it’s the 1024-bit RSA or the MD5 signature thing then? ✏

tell flow 2015 called and wants him to use letsencrypt

no CAcert isn't a trusted CA

I imported it once

Everyone must use Let's Encrypt!

since I used it myself extensively

Zash, *Everyone MUST use Let's Encrypt!

jonasw, probably Signature algorithm SHA512withRSA

that's, not exactly standard

https://www.ssllabs.com/ssltest/analyze.html?d=geekplace.eu

meh, that link re-analyzes

oh I didn't think it did, that's annoying

your problem from your error message is you disabled SHA512withRSA as a cert algorithm, or, if you don't have CACert as trusted, it's root cert is signed with MD5withRSA

whatever it is

I hate to say it, but the site works with http too...

jonasw: To answer your question from the editor@ room, there is no successor to the trademark license enforcement agreement of May 2003. That's when we were transitioning from JSF/Jabber to XSF/XMPP (read the list archives, someone called me Hitler!), and interest in registering anything with the word JABBER™ in it had already waned. It's fascinating to me that this issue is still alive 14 years later. :-)

peter, also from https://xmpp.org/docs/Trademark_License_Agreement.pdf what does point 5. mean "No Right to Assign or Sublicense" ?

I'm not a lawyer which is why I'd universally prefer something not trademarked like 'xmpp' than something I have to ask questions about like 'jabber' :(

peter, I’m confused then. on what basis does the XSF operate according to the Exhibit A of the Letter of Intent, the text which has now become the usage guidelines on the website?

moparisthebest: that means the XSF can't assign its right to sublicense the mark to another organization.

that makes sense I guess

jonasw: what's the URL for the letter of intent?

and hopefully it wasn't an 'assignment' to go JSF -> XSF ? :)

peter, https://xmpp.org/docs/Trademark_Letter_Of_Intent.pdf

moparisthebest: no, that wasn't assignment, just a legal name change for the organization

(that text I am talking about (Exhibit A there) is the Jabber Trademark Position Statement, which I couldn’t find elsewhere; it is referenced as basis in the Enforcement Agreement)

also, wtf, that mailing list thread from back then

jonasw: I'm confused by your confusion. :-) Could you explain your concern a bit more?

peter, I’m still trying to find the legal documents which give the XSF the permission to sublicense Jabber, as we were wondering if and under which circumstances Cisco could terminate our (the XSF’) right to sublicense

OK.

I can’t read that from the License Agreement, because the terms the XSF seems to be operating on (the part of the Exhibit A / Jabber Trademark Position Statement / Usage Guidelines on the website) is not referenced there

but IANAL, you have been there back then and may know more

also, to lighten things up (quoting from that mail thread): > He is an extremely patient and tireless driving force > who deserves a great deal of recognition. Shame on you for your lack of > support. That is my perception, and I’ll use this opportunity to say Thanks for that.

Aw, thanks. :-)

jonasw: BTW are you a native speaker of English? If not (and even if you are!), these legal documents can be difficult to understand.

I'm a native english speaker and still have problems groking lawyer-speak :)

peter, no I’m not :(

(the issue with legalese in any language is of course that you often don’t know you didn’t understand it :()

still I’d expect some document which defines the guidelines under which the XSF can sublicense (but I may be wrong), but there doesn’t seem to be one if the Enforcement Agreement didn’t have a successor and expired (like I read it) after 12 months.

the enforcement agreement he is talking about is https://xmpp.org/docs/Trademark_Enforcement_Agreement.pdf

thanks, moparisthebest

and I also read that it expired after 12 months

So, a letter of intent is just that - a statement of principles and intention to work together toward something (in this case, an actual agreement regarding the trademark). At that time, there was quite a bit of controversy in the community about Jabber Inc., a drive to change the name to XMPP, and so on. The letter of intent was communicated to the community in late 2002, and as a result we developed the actual license agreement in March of 2003, and following that the enforcement agreement in May of 2003, see http://xmpp.org/docs/Trademark_Enforcement_Agreement.pdf

Ah, yes.

but that expired in may of 2004 right?

There was supposed to be a 12-month "trial period" and then a discussion about potentially transferring the trademark to the XSF. Everyone got busy with standardization of XMPP at the IETF and with business as usual at Jabber Inc. I seem to recall that we addressed this a bit later on. Let me go AFK for a few minutes and look in the physical files, which are in my home office here. brb

thank you for your effort, peter :)

man he really is the best, no one else would get up from a desk and thumb through files :)

haha

OK, so I don't see it in my physical files. I'll need to check the email history.

My personal email history does not reveal anything, either. I do have a recollection that we addressed this 12-month topic at one point, but it was a long time ago. I might need to look at the archives of the board@ list.

Oh, but we decided not to have archives for the board@ list. :(

sure? the mailman claims it is members only

Don't we have any at all, or perhaps no public ones?

you don’t find them at /pipermail/board, but at /mailman/private/board

here: https://mail.jabber.org/mailman/private/board

I have admin privs on all the lists and I just checked.

ugh

To bad

The Board Archives Currently, there are no archives.

so for all we know the XSF currently does not have any authority over the Jabber™ whatsoever?

I can ssh to the machine and poke around.

jonasw: the XSF has authority, just not completely *documented* authority.

okay :)

I've been in communication about various trademark issues with JINC legal counsel and Cisco legal departments before JINC was acquired, after JINC was acquired, and after I left Cisco. There has never been any question that the XSF has continued authority to sublicense use of the JABBER mark.

And I made sure that this was specifically re-affirmed when Jabber Inc. was acquired by Cisco in 2008.

We just don't have a good paper trail on things after 2003.

Alex perhaps?

peter, just recently there has been a bit of a push to revive 'jabber', and I'm more concerned if you get hit by a bus and cisco turns evil, they could probably just pull it?

at least if there is no paperwork

I can ask my contacts at Cisco legal if they have any additional paperwork.

even now I'd guess recollections wouldn't hold up in court

Guus: I've always been the keeper of the paperwork.

K

I'd be more worried about the bus factor than "just pulling it".

After all, Cisco's (and before that Jabber Inc.'s) actual *behavior* since 2003 shows a continuous recognition that the JSF/XSF has the right to sublicense use of the mark.

However, it would be a good thing for me to reach out to my contacts in Cisco legal because (a) people come and go (b) the new people don't necessarily know (c) maybe they have copies of something I don't have.

that's true I think they do heavily consider past, uh, actions/behavior

I'm slightly worried that Cisco legal will contact "the XSF" with a 30 day deadline to handle some specific case of trademark misuse, and that letter won't arrive in time (or board won't meet in time) and we will lose our sub-license.

Ge0rG: Thanks for your concern. When I reach out to Cisco legal, I will mention the desirability of having a backup person to contact in case I get hit by a bus.

(also, we'd be bummed for other than trademark reasons, Peter)

thanks for clarifying Guus :)

trying to spread the love ;)

Guus: :-)

peter, if you have time for another, although more trivial, issue: according to Raja, you and someone else were involved with creating the xmpp logo.

I've asked him about that weird orange bit that continues to bug me. He is going to check his original designs, but was confident that it wasn't him that designed it like that. But, from what I gather, the design was a team effort of sorts

context: https://github.com/xsf/xmpp.org/pull/363

so, as a potential co-designer of that logo: what's your take on it?

I have a graphics idiot and would not have been involved with that level of design. :-)

s/have/am/

Guus: you contacted Raja Sandhu about it?

I don't recall anyone else being involved.

yup

He's a nice guy, say hi for me. :-)

he mentioned you and someone else that he couldn't name.

huh

I never weigh in on graphics stuff because I know nothing.

It was probably Matt Tucker.

I think Matt introduced us to Raja.

fair enough. It's a long time ago

ah, I wondered about that. I saw Jive's logo in his portfolio :)

Matt was CTO of Jive Software back in the day.

He's started something new recently, I should check in with him.

peter, Igniterealtime FOundation, for one thing. :-)

Matt and me talk on occasion - he joined the Ignite Realtime Foundation board

but he started a new business too

not igniterealtime, something more recent

yeah

Koan, iirc

https://koan.co

that's it

peter, thanks for all the clarifications :)

So says LinkedIn, anyway. ;-)

jonasw: sure thing!

I have a phone call here in a few minutes, bbiab.

peter: my concern wasn't even the bus factor but just potential practical issues with a process that's not exercised but has grave consequences when it fails....

who's controlling our website? As in: do we have a work team?

Guus, thanks for adding that commit, I totally forgot

no worries. My grand plan is to give you access to modify the website yourself.

we could use some additional merge-button-pushers

and you're effectively doing most of it anyway :)

don’t count on it now that I’m editor

meh, it's just about you having the ability to press 'merge'

yeah, hitting merge is responsibility ;-)

so that someone active, other than me, can apply changes if I fall of the edge of the world for a bit.

jonasw: no more than providing the PR itself :)

People could inject evil things into their PRs, like matrix propaganda. We need to watch out!

😀

The Matrix was a great movie

so nothing wrong with that

what about the sequals though

which sequels?

good answer

but, my original question: who gets to say who gets access?

Guus, interesting question :)

is website a subset of social media? ;-)

gajim has decided to color Guus and Ge0rG the same and between that and the G I can no longer tell the difference :'(

Guu0rG

didn't you guys have a proposal for fancy coloring?

or, consistant coloring

moparisthebest, yeh

I have a pre-proto-xep in my xeps dir

I should add some finishing touches for ProtoXEPing it

yes please

It turned out to require fancy floating point math

not *that* fancy

Like my last proposal for MUC limiting.

muc limiting does FPM anyways

(as does anything in lua)

In LUA

for a super optional client-side coloring xep I think a floating point requirement is acceptable

do we still have a technical review team?

it's purpose apparently is to find out how we can help stPeter more. :)

Least Usable Algorithms.

https://wiki.xmpp.org/web/Review_team (I recognize but a few of the member names - possibly due to out-of-date content after the crash recovery)

This page was last modified on 26 August 2011

https://github.com/xsf/xmpp.org/pull/365

I was going to add just SCAM, but I tried to make it consistent by adding all teams.

As noted against the PR, I think two of those teams are dead (and one is not a team, but a SIG, but lives yet).

The two are Comms, Review, and UPnP. Let's start again. Nobody expects the Spanish Inquisition. Our three defunct teams are...

You lost me. 😁

Ah, three defunct teams, according to you, are Comms, Review and UPnP.

Do we have members of those teams here to confirm?

Peter, Kev, Nyco, from memory...

moparisthebest, I took a look at my draft for the color protoxep. there were a few edges to polish, unfortunately I’ll head to bed now. hopefully I get around to publish it tomorrow.

sweet, no rush

Guus, No, Kev wasn't ever on the Review team, as he was on Council throughout its existence (as was I, I think).

Guus, I'm not sure anyone who was on it is still even a member.

let me check when upnp was done (aka: spec published)

the upnp spec was published in february 2015 @ http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v2.0.pdf

fippo: what does that mean in regards to the teams existence?

guus: "job done" i'd say

and upnp.org seems not to exist anymore

still registered though Open Connectivity Foundation, Inc.

well, didn't notify the XSF about the change in name so... :-)