XSF Discussion - 2017-09-27

Guus, Ge0rG: Coming back to the 'new' Foundations discussion. My intention is a) focus on important issues in the xmpp comunity in general b) maybe put paid devs on these task or specific clients which are likey to improve the UX of xmpp in general (yes, money is an issue i know) c) build a platform/website to show what xmpp can do for standard users who never heard of xmpp before d) may provide general information about the network (number of users, how does xmpp work etc) - you get what my intention is? I dont talk about if that's likely to happen. I ask whether is the right way?

emxp: I don't know. There likely is not one right way. If you see value in it, by all means.

emxp: (a) yes, 100%. I'm trying that for a while now. (b) not only money is an issue, fair distribution of the money is as well. (c) I'm not sure people are reading such websites, but it might attract some nerds / multipliers, so yeah! I wish we could host it on jabber.org... (d) that's actually hard. The XSF is trying to, but you can hardly get reliable data from a federated system like XMPP

If you are good at fund raising by all means go ahead. I don't think developers will say no to money

Ironically fund raising is a full time job. So as soon as you start you'll have to raise enough money to at least pay your own salary

daniel: actually, to pay for two people.

...so that you have one effective developer

My personal approach is to create a sustainable business model. I know that's quite revolutionary idea in today's world. But you it might be more... sustainable...

sustainable model is to get hired :D

daniel, did you think about pitching your idea to a VC to get funding? :p

zinid, only if that company itself has a sustainable business model. i'm sure the matrix developer can agree

I've heard that Erlang an C++ developers are in high demand...

daniel, Ge0rG: For me there is no direct discussion of fairness. the foundation can act transparent, only invest in open source code and only spend money to task/work they all agree to. based on some principles - opensource, leading for xmpp, of intrest for xmpp community etc.. If people dont agree to those projects, they wont spend. so the foundation is forced to define task which are in the interest of most xmpp users somehow... or they can define task, the necessary effort, and let people donate and offer like 10-20% of the necessary amount. It's better to have a central plattform to collect task, than wait for third party aproaches maybe

I think most people, dont like to donate, if they have no idea, about where the money goes

Pushing only OSS projects sounds like a Really Bad Idea, given where so much of the XSF's expertise and effort has come from over the years.

Kev, yeah, although I can see the point if people are donating the funding

mathieui: what do you mean exactly

Kev: Just an example. What software would you suggest to support?

Some may find it weird to donate to commercial projects.

Ah, this is a separate 'pay for software' foundation? I thought you meant the XSF.

If it's some 'pay for opensource XMPP foundation', it's fine to focus on open source.

Zash: Sure, so it has to be both non-commercial and open source? :)

Kev: I think that OSS is the only way to ensure that the software won't just fold up and die at any moment in time after or before the funding stops.

Ge0rG: I don't think OSS ensures that at all. But I understand what you mean.

Kev: with closed source, there is no way at all to achieve that.

Kev: and there are many viable business models around OSS, so I don't think this is about offending commercial closed-source providers.

Also not true, but it's harder to get anyone to agree to it.

Kev: it's always hard to agree on how to spend money. Your first remark is a good example of that.

Ge0rG: If the business model is viable, we don't need a new foundation to be fundraising to inject money, I suppose? :)

Kev: so we need to focus our money on non-viable business models. Wow, that sounds like a very awful framing of paying for non-commercial OSS development.

I don't have any problem with someone running a "raise money and we'll give it to projects" org, BTW. I misunderstood and thought it was suggested to do it through the XSF, which I disagree with.

I think the prospect is filled with difficulties, but as long as it's not the XSF that's shouldering them, more people working in XMPP is good :)

The more I think about it, the more I like the idea of resurrecting the Jabber Software Foundation.

Which is my second "it used to be more appropriate in the past" epiphany after "message routing was better before Carbons, and we should try to get back to it"

✏

Routing was better before carbons?

Ge0rG: I suddenly have this urge to tell you something along the lines of "I told you so"

Kev: I've been pondering about how to improve the message routing mess we are currently in, and my proposal for a future XMPP would be this: - messages to the bare JID are persistent, routed to all online resoures and archived - messages to a full JID are ephemeral, only routed to the target full JID (or bounced) and not stored.

- resource locking must be burned with fire.

and this is very close to XMPP message routing rules pre-Carbons

I'm fine with that in principle, although we're not ready for "resource locking must be burned with fire." because of not having a sensible caps story yet, but we could get there. We need to anyway, because of carbons.

Except there is no sane way to get from here to there.

Kev: because of carbons and archives.

There are ways though

and race conditions.

The idea of not doing full-JID fallback is sensible enough, in a MAM world.

But only if you archive. Hmm.

Kev: if we make full-JID synonymous with ephemeral, there is no need for fallback.

But reassigning the semantics of full-JID is a tough call.

Except for requiring a forklift upgrade.

Kev: I'm open to less radical suggestions.

I was trying to think through whether it was possible for a 'modern' client on a 'modern' server to accept messages in 'old' style, but still do sensible things.

Kev: but I think it's important that we analyze the situation we are in, determine that it's a huge mess, and have a vision of where we want to be in X years.

I guess there is.

If we in some way mark sessions as being xmpp 1 or xmpp 2.

Design from the top instead of the bottom?

Kev: https://wiki.xmpp.org/web/XMPP_2.0 ;)

Ge0rG: I don't disagree with that. I've been trying to do this for some time.

(that being working a way out of the mess)

and I'd love that vision to be "XMPP(-IM) is a transport protocol to synchronize a message history between a user's devices on login and live.

plus what we have with presence, that's working well more or less.

I think a long session at the next summit would be justified.

Zash: yeah.

Kev: +1 to that, though I don't know yet if I can attend.

Or a fully-virtual summit.

Ge0rG: Yeah, I too have this feeling that we've built a bunch of things that we don't know how they are supposed to fit togeather.

Or just a video chat between interested parties. Whatever.

I don't think IM/mail is the most productive way to work through such a core issue.

(But I could be wrong)

Kev: I think that whoever is going to attend a live meeting needs to understand the problem first.

FOSDEM isn't too far away?

Zash: it's not just a feeling, it's our current situation. Have a look at the interop between MAM and MUC, MUC and Carbons, etc.

Even presence in MUC is a challenge.

And the current situation is sufficiently f***ed up that we can't fix it by piling more protocols on top.

I think needing to understand the problem is why high-bandwidth is useful.

I'm not at all convinced that it can't be fixed by building on top, though.

I'm pondering about writing something long-ish to explain the problem as I see it and possible solution directions

Ge0rG: MAM, MUC, Carbons, SM, Push, CSI etc

Zash: yeah.

All your examples there included MUC.

And the number of things involved has grown to be more numerous than what fits in my head

Binning MUC and replacing it might be an idea...

Kev: what Zash said.

Kev: how should Carbons and MAM interact with 0184 ACKs for example?

I think they're all necessary. Whether they're called individual things, or xmpp2core just gets really long.

You need archiving, you need groupchat, you need routing rules, you need app-level acks, you need push, you need bandwidth management...

Kev: all those things are needed, yes.

Kev: that's not the question. The question is how to make them work together.

They are all individual patches for individual problems, and they interop badly.

I'm far from saying everything's perfect. I challenge the notion that things can't be fixed without binning the core, though.

And we certainly need The Big Picture sorted.

Kev: this is not about binning the core.

Kev: but about some of the assumptions it made that are not appropriate any more.

You'll remember (you won't, actually, because it was before your time :)) that I started a protoXEP for this many many years ago, but we didn't have the building blocks to solve it. It was in the days before MAM et al.

Kev: I'm not intending to replace XMPP with JSON-REST. But I want to start from The Big Picture and see what needs to be changed to make XMPP2 work well.

I'm very much in favour of big-picture here.

Kev: Yes, i was talking about a different organsisation and if my thoughts are senseful

And big-picture needs a big whiteboard! :)

Maybe Ge0rG should publish a Thought-A-Day on each of the problems he sees with the current state, so it's not TL;DR, and at the end of the series we've got the full picture :D

Kev, I thnik he started a blog series :)

Odd, I thought I had planet jabber in my feed.

does the xmpp.org blog federate to that?

I'm lost, xmpp2.0 is coming?

just don't use XML anymore :)

funny

or JSON if that matters

JSON is XML of nowadays

kids from 2030s will laught at us again

Wake me up when ASN.1 is cool again

never?

it's not modern, ya know

protocol buffers is THE THING

actually, protocol buffers is one of the saner protocol designs.

Zash, ASN.1 over XML over JSON over HTTP over XMPP over VTEP

Ge0rG, I’m not convinced by their implicit defaults.

Kev: I've started a blog post series on "Easy XMPP", which is different. I think for this one, I'd rather go with my personal blog and the "xmpp" tag there.

jonasw: admittedly, I haven't had a deep dive into it. But any protocol that doesn't implicitly encode data lengths and uses escapable special markers is sane for me.

jonasw: Considering ASN.1 being something of a schema thing, and the existence of an XML encoding of it ... I wonder if there's a JSON one yet.

https://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c89 was an awesome post showing that all the modern web protocols actually fail the same way the US telephone network did in the 70ies. Mixing of meta-data and data.

Make Gohper Great Again

The author is calling it "buffer overflows" and meaning "lack of explicit buffer lengths", but it's all the same story.

Don't LangSec people say that that's a giant security hole too?

Zash: that what?

Kev: I'm just not sure if I can start with individual problems and somehow arrive at the big picture.

Whop's, bit got flipped in the length field and everything turned into a giant buffer overflow!

Something something length fields don't fit into some simpler language category?

Ge0rG: why not prefix length? you can parse it in parallel, unlike scanning

Because Heartbleed?

Length prefixed fields helped so much there

Zash: the issue with heartbleed was conflicting length fields.

Zash: using same logic I would say don't use C then

zinid, that’s a reasonable statement :-)

well, yes :)

Zash: besides, my point wasn't that old protocols are sane, just that the current ones are mad.

yeah, like http2

tcp over http, wtf...

Gotta let Google have their optimizations

right, today everyone is accepting what Google suggests, to be exact, what's good for their bussiness

IETF is degrading

W3C has fallen.

zinid: https://jacquesmattheij.com/the-web-in-2050 is for you :P

Ge0rG: wait, I didn't finish reading your first article (about kill web)

Ge0rG: for the record, from your article: > The fix: All buffers should be length prefixed from database, to frontend server, to user interface. There should never be a need to scan something for magic characters to determine where it ends. Note that this requires binary protocols, formats and UI logic throughout the entire stack.

I forget where I read it, but you shouldn't underestimate human-readable protocols and formats. At least not for early versions. Later versions being binary might be sensible.

It was kinda cool way back in the day to open the XML console and see something that made sense.

Or View Source and reading the HTML and stuff.

can't do that anymore tho, not with all the minifications and whatnot.

Zash: yes, it was cool because there were no encryption, I used tcpflow for this ;)

Not sure why $length:$readable_data would be impossible though.

actually, there can be well-defined mechanism to dump structures in human-readable form

like they do for WebAssembly

Do binary protocols usually have that tho?

Like, included by default and accessible?

Zash, protobuf does

Zash: I don't think so, but it's not that hard to write rules how to dump protobuffs structures for example

Zash, $homebrewbinary probably doesn’t

and dumping structures is trivial and not error prone (almost)

unlike parsing them

Sure sure, but text formats make it really easy to get into fiddling with things, which helps with early adoption.

Of course it comes back to bite you later, but still.

*shrug*

XML worksforme

this is the same argument as Python vs Haskell

Python will bite you later for sure

duck typing accepts no excuses

Duckt tapeing ftw

duct taping?

kinky

DuckDuckTape?

Holger: it's not impossible with human-readable formats, but then you end up with whitespace or newline in the wrong place and the parser freaks out :(

Ge0rG, #poezio? ;-)

anyway, I'm relaxed, because I implemented XML codec for ejabberd, it does the same as asn.1/protobufs/etc and it works (despite everyone cries you should not validate)

jonasw: no way :P

Ge0rG, a good example of a working system is the chunked HTTP encoding

jonasw: how many HTTP entities will accept unix LF instead of CRLF, what do you think?

Ge0rG, right, it’s CRLF

The finer points HTTP header syntax will make you mad

Zash, I’ve seen a fun talk about that

forgot how it was called

jonasw: also is there a CRLF at the end? https://stackoverflow.com/questions/33878377/why-are-some-servers-not-using-crlf-after-the-last-chunk-length-of-zero ;)

but they made ascii-art out of well-formed HTTP headers, soo....

TIL there are trailers

movie trailes? or the ones you live in?

Ge0rG, the ones behind the last chunk in chunked transfer encoding

read the answer you linked :)

Oh. My. God.

> tcp over http I start twitching every time I hear that because it makes me think of BOSH…

bosh... plz god no

speaking of which, anyone feel like going around the interwebz and purging old pre-standard xmpp-over-websockets implementations?

Sorry, I have a soft spot for BOSH

I have a bunch of issues related to mod_bosh, it's brutally hard to debug with all that overcomplicated sid/rid/cid crap

just terrible protocol

Indeed… impossible to debug, hard to implement in any reasonable way, can't really be decoupled from the underlying thing it's transporting (although the XMPP over websocket protocol is that way too)

Thanks Web & JavaScript!

it's a right pain.

There is a followup to kill-the-web: https://blog.plan99.net/what-should-follow-the-web-8dcbbeaccd93

CORBA YEAAAAAh

have you heard of dns over http aka DOH?

fippo: It needs moar JSON

Can't we deprecate bosh btw? Do we still need it when we have websockets?

https://caniuse.com/websockets I suppose we could

zinid: are you going to pay the developers of all BOSH clients to migrate?

Also I wonder how that will work with TCP interruptions, bad firewalls / web firewalls, etc.

Also how good is WebSocket library support for non-webbrowser applications?

Maybe we should have standardized two xmpp-over-websocket versions. One with WebJS fiddlery and one that's just the same as TCP but over WS

Does Websockets work with all those restrictive corporate firewalls that are forcing everything into becoming https on 443?

Zash: I think WS is masquerading as HTTPS, but of course with irregular traffic patterns.

Zash: so it will work with the subset of firewalls that don't look too deeply into the traffic and don't have low timeouts

zinid, excellent work on TLS SRV patch :)

> are you going to pay the developers of all BOSH clients to migrate? Wow, we now care about backward compatibility? What about private storage, vcard avatars, privacy lists? Who payed the developers?

moparisthebest: thanks

zinid, nobody, and most clients are still using private storage

regarding firewalls: it's just https traffice, timeouts will be handled by stream management

mathieui: I know ;)

zinid, I think we still need BOSH. We have to use it on occasion.

I'm biased, but I think web clients use websockets, and non-web clients use direct TLS, both are equivalent when over 443 as far as evil firewalls go

moparisthebest: I think this webby stuff is mostly for browsers now, no?

not sure why would a non-web client use bosh/ws

iirc gajim has a bosh implementation

but I agree it *should* be

dwd: can't we use ws occasionally? :)

We experience browsers with websockets explicitly disabled. This is far from ideal, but still, they exist.

dwd, I didn't know that was a possibility

zinid, when you have no other choice for direct connection, ws/bosh in desktop clients seem like a nice fit

We experience browsers too old to websocket, too.

(Yes, yes, I know, I know, but they do)

hopefully they will be 0dayed into history before long

damn, so I need to fix those mod_bosh bugs :(

thank you!

zinid, Also, I don't think your IPv6 is working.

dwd: it doesn't, yeah

something wrong with firewall probably

Kev, No, we're seeing new browsers, but with it disabled. And no, I didn't know either.

mathieui, but for a desktop client direct TLS is also a (far easier) option whenever ws/bosh is

dwd: Yes, you said that, I didn't doubt it.

moparisthebest, sometimes you cannot

dwd: the problem with ipv6 is I have nowhere to test it from

dwd: I don't have ipv6 at home, so...

mathieui, aren't you connecting to ws/bosh over direct TLS ?

unless you mean, fully in-the-clear-no-tls-xmpp :/

moparisthebest, sometimes non-standards ports are blocked

no, I mean, you can proxy those from 443 with nginx

and you can alpn (or protocol-inspect, ew) xmpp and http to xmpp server or nginx on 443

it all depends on the server to have it set up properly, but bosh/ws does too

moparisthebest, alpn will be blocked by firewalls if they really want to

yes it can be, and probably will one day, but not by wifi hotspots in coffee shops most likely

also why it's not required, daniel and I talked about it back in the day, conversations will probably try with alpn and if it fails then without it, or vice versa

not *yet*

so today, using alpn, you can have client -> sslh (based on alpn) -> (prosody,nginx)

yeah, ALPN is a really bad idea if you want to bypass the DPI: you're literally saying: "hey, I'm jabber"

today you could also, without alpn, have client -> stunnel (or something decrypting TLS) -> sslh (based on xmpp/http) -> (prosody,nginx)

the original spec sent the SRV name in SNI and used that to multi-plex :P

no one liked my wanton abuse of SNI though :'(

moparisthebest, Wouldn't work in Java, I think.

for the record, I heard it TLS v1.3 sni and other extensions will not be that easy to inspect

can somebody confirm?

I tried to read the I-D, but it's brutal

yea TLS lib support for "serve the certificate for xmpp.org when server1.xmpp.org is in SNI" is probably spotty/non-existant

I used sslh to multiplex on SNI and prosody just served the 1 cert regardless meh

zinid, I know people were pushing to encrypt SNI/ALPN but last I heard it was abandoned to the future, they might have done something to obfuscate it or something, not sure

moparisthebest: too bad, because the government firewall is annoying (it detects SNI)

which government?

russian

ah that sucks

zinid, We could work around that.

zinid, Use starttls to establish the session and then resume it on directtls.

you are just announcing it another way, also they could inspect the certificate coming back couldn't they?

dwd: but starttls can be detected easily

so my work on 443 just holds your connection up temporarily, connects on it's own to see if the TLS handshake succeeds (and only supports TLS 1.0), and only if successful lets your connection through

so if you only support TLS 1.1+ it won't allow that either, without also supporting 1.0...

yes, they could inspect the certificate

so I would prefere all parameters to be encrypted

*prefer

it's a shame to have to consider that at a country level

but nowadays even 'free-er' countries like UK look like they are moving in that direction...

right, you never know who's next

so this should be developed now

thus I'm wondered the TLS folks abandoned the idea

it's been a year or two since I looked, hopefully it was picked back up idk

the reason was because it breaks all the multi-plexing TLS business like I do with sslh

so akamai and such were super against it

https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

August 29, 2017

safe to say it's actively being worked on

but 20 pages...

Weren't all the CDNs strongly opposed to that?

ha yea it's not short

oh you said that

20 pages is not what?

but whatever they come up with there in theory should apply equally to ALPN

Zash, he is saying https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00 is 20 pages long

moparisthebest: there is a lot non-normative text, it's fine after all

I can't find anything about ALPN encryption

I hadn't seen that; might be interesting to try and do an early implementation in our TLS 1.3 stack. I might give that a shot one of these days if I can convince my boss to loan me to the crypto team for a bit.

Does it look relatively implementable in its current form?

https://signal.org/blog/private-contact-discovery/

edhelas: We saw it.

mimi89999: in another chatroom ;)

If we all are in all the same rooms, can't we just merge them into one?

Ge0rG: You are the one who started another? :)

... after people complained about off-topic discussions here

The off-topic discussions there are too on-topic!!

Zash: that's not my fault.

Ge0rG: 😁

last time I checked there was dead silence in this room

now it's active, that's cool

zinid: board meeting approaching

Ge0rG: nah, I mean several years ago

ding

dong

Ding ding, board o'clock

Looking promising :)

hey

4/5 this looks very promising

ralphm, ?

I have to leave at :30 max

Ok

i cant stay much beyond :30 either

Ok, let's get cracking then

1. Roll call

Here

Here

Présent

2. Minutes, any volunteers? dwd?

I can do it

but I’ll also have to leave at :30

Thanks jonasw, much appreciated.

3. Topics for decisions

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

3.1: Logo amendments. Struggled to get this tied off last week, thoughts?

+1

+1

I think it was left last week that ralphm wanted other board members to express their opinion as well

voted on the GH issue

done

I was in favour, but it seems some folks are fairly against the change

I continue to be +1, for the record

OK, me too

We are the only ones who even notice the glitch. It doesnt substantially alter our logo in any way a non-xsf member would ever notice.

we notice it because we end up with it in front of us in inkscape, like guus did

board is now 4 times +1, one time 0.

(and btw, I printed the "fixed" logo on the trifolds for fosdem and nobody even noticed)

Arc: someone did.

*twitch*

Yes, I did :(

That was supposed to be a happy smiley face, issues for using more than one keyboard layout.

That logo has been triggering my OCD for years.

OK, so we're decided, it's approved

Moving on

4. Commitment list

4.1 D&0 quote?

in one sentence for the minutes, what’s that?

no news? let's move on?

jonasw: I don't know. There's nothing more in Trello and this card precedes me being on Board

I am amused.

stpeter is assignee

I won’t put that in the minutes ;-).

thx

Council/board bios?

Arc and Martin, type here a short sentence! ;-)

4.2 Board bios

You chose the version where the 2 parts of the logo don't cross?

Will do my best

Hi. I'm commuting, but following along

next item?

5. Items for discussion

5.1 XSF Editor team. There's a comment from Guus that this might be solved?

.

…ok… anyone else got anything on this?

I suspect no.

nope, next? ;-)

I have no basis to say anything on the topic

5.2 Legal notice on old public domain XEPs

https://github.com/xsf/xeps/pull/345

Looks like it's been merged, so I think the card's out of date

5.3 Ongoing marketing activities & budget. It seems I added this card, but back in February, which is definitely too long ago for me to remember what it's about

you know we can, for once, close the meeting early :-)

So if we don't know what to discuss, can we remove it?

ralphm: That's what I'm doing. If there's nothing, it's gone.

I have one minute thing: elections

yes please

Shouldn't we have started this year's round?

5.4 Blog post on hold: nyco?

is that anything board needs to discuss?

Nothing. OK. Next. AOBs.

ralphm: Elections?

Yeah, sorry for jumping the agenda

blog post is published, so unblocked, but needs some fixes, in discussion with Guus, card can be archived

But we need to have them

Alex, you around?

ralphm, Alex said he was working on it

what elections?

I missed that

^

what elections? board?

a couple of weeks ago

Council and board

jonasw, yes

yeah, alex mentioned he’d work on it after the Q3 application meeting

Indeed, Alex mentioned he was going to address that soonish.

"ASAP" were his words back then :)

Ok. Martin can you put that in our Trello?

our last job as a board

What, no

Preparation takes weeks

Finding candidates, then the online voting, etc

i mean, seeing a new board into their new role

(is board involved in the prep or execution?)

Well ultimately we are responsible, yes

Details are in the bylaws

Also

Guus: tricking, er, fooling, er, convincing 5+ people to take the role is the board's responsibility. we can't leave until its done

itym "welcoming"

We should all consider if we would like to run again, as will council, and try and find good candidates for board

jonasw: yes, "welcoming"

I always get those confused :)

I'm gone, sorry, bye all!

Thanks nyco

yea i need to head out soon. is there AOB?

I think we're done

The XEP status thing?

Think we're done, if people are going to start breaking off

Didn't Sam add a card?

meh, someone forgot to put that on the trello I’m afraid, Guus

Thanks!

ah, no it was there

Guess we're done?

Ah, yes, "Rename Draft to Stable"

but ralphm interrupted the agenda before it could be reached

yes I am here, cacthing up o the messages :-)

is it pressing such that we can't do it next week?

personally, I don’t think so

Not pressing I think

It's not pressing

Agreed

Right, then we're done.

+1W for next?

+1W

Yay. Thanks for chairing Martin

Wfm

yes thanks for chairing

Thanks

Alex, can you give me a quick statement for the minutes on the status of the preparation of the elections for board & council?

thanks ralphm :-)

jonasw: I was trying to find out when we had the election last year, need to look this up on teh memberlist, becasue the meeting minutes form last year are not on the new Wiki

okay

I’ll note that down as "preparation in progress"

Last year was too late

with some "data recovery needed due to data loss"

wanted to do this this week, but had to travel unexpted again then for the whole week to a customer

We've been slipping over the years. Used to be in August

hopefully I can get some work done in the hotel in the evenings

Cheers

I know how life can conflict with foundation duties

Alex: need a hand?

https://mail.jabber.org/pipermail/members/2016-September/008346.html

https://mail.jabber.org/pipermail/members/2016-November/008397.html

ralphm: yes, but we also said we should stick the 12 month term

Yeah, I know

So this is a good time to start then, right?

we had discussion a while ago to either make a term longer or shorter once, and agree on a fix schedule

I think Peter proposed a calendar year, Jan 1st to Dec 31,

ralphm: yes, this is why I have it on my TODO list for this week

I can setup the Wiki page this evening, and send out an Email

Yay

calendar year makes sense for serving times, you'd still want the vote (much?) earlier though to avoid voting over holidays/new year

It seems like if you did calendar year that the first meeting would never happen because people would be on vacation.

that TLS SNI encryption RFC is making my brain hurt

RFC? Wasn't it an I-D?

moparisthebest: it's http fronting, not sure how it's better than tor for example

I read it too

I should figure out how the printer in this building works so that I can read it…

easy in fact

The current draft proposes two designs for SNI Encryption in TLS. Both designs hide a "Hidden Service" behind a "Fronting Service". To an external observer, the TLS connections will appear to be directed towards the Fronting Service. The cleartext SNI parameter will document the Fronting Service. A second SNI parameter will be transmitted in an encrypted form to the Fronting Service, and will allow that service to redirect the connection towards the Hidden Service.

that's all

SamWhited: PC LOAD LETTER

I should figure out how to turn arbitrary RFCs and I-Ds into epubs or something I can read on the eink thing

It's a pain, but at least I don't have to deal with printers.

what is a problem to ban this "fronting" sni?

I really don't get it

Wait so it's TLS over TLS???

Zash, https://tools.ietf.org/ebook/

Zash: yes :)

kinda

rfc-std.epub appears to contain all the RFCs. It doesn’t take at all long to load on my machine....

I believe I have one of those already

Not the most optimal to navigate unfortunately

ah, I got it, you can use any junk in the Fronting SNI

probably :)

Zash, it's got txt/xml/pdf/html/bibtex

what?

https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/

anybody using this https://xmpp.org/extensions/xep-0146.html

moparisthebest: those are not what I want

pep., I thought council voted to deprecate that?

Doesn't seem deprecated to me, yet. "Last Updated: 2006-03-23"

But I could see why

https://www.zash.se/upload/-kIpyeZzS4C6LOXuehhxhQ.jpg

pep., Council meeting minutes 2017-08-30: Vote on obsoleting XEP-0146 (Remote controlling clients) Period has expired with missing votes from Tobias and Dave. Dave and Tobias say they are happy with their implicit +1s.

so, officially, it's deprecated, I think? editors? :)

k

or obsoleted

moparisthebest, oha

I remotely recalled there was something like that, thanks for pointing this out

moparisthebest, I can’t find it in the council minutes you mentioned, are you sure it’s the correct date?

ah, nevermind

found it

yeah, that indeed needs Deprecation

jonasw, btw if you want to add alpn support to your client I can give you a test account on my server

jonasw: btw a big reason why I wanted xep->markdown was to produce epubs using pandoc, and it works pretty well for that

https://xmpp.org/extensions/xep-0267.html what about "Server Buddies"? Anybody using it?

I wanna use it for all sorts of things, but haven't gotten around to it :(

pep., this references it https://blog.process-one.net/wp-content/uploads/2016/07/Fighting-XMPP-messaging-spam-thanks-to-ejabberd-API.pdf

more in a 'for the future' way

cool, thanks

I've applied the logo change in most of the obvious places

if someone finds an old logo somewhere, please let me know

Google Image search is full of it...

DMCA