XSF Discussion - 2017-12-10

Yeah, and they should be square (or round, council would decide it)

No, they need to be properly displayable in both round and square elements, and they also need a secondary graphic that can be used as a 16:9 background

Ge0rG for this I'd advice to add a "background" picture, like on many other social networks

And we also need a sarcasm tag!

:X

Or at least an according Emoji

Openfire has a plugin that allows administrators to reduce the size of to large avatars. One of the XEPs does define a preferred size. (I _think_ it's 96x96 pixels).

I think we should significantly increase that, maybe to 512*512?

Ge0rG: I'm not sure about the defined size in the first place.

I haven't had a look into avatars yet. Need to fix message routing and MUC first

For avatars (icons), 512 seems excessive? Full profile picture, sure, but the picture in a roster or next to a chat message?

Guus: I'm sure clients will (ab)use the avatar as a profile picture if they can get away with it

Ge0rG, regarding PARS: what if I have multiple clients (A and B) and invite C with client A and C accepts the invitation while I'm online with B only?

marc: with the current text, this will be a normal manual fallback. We've talked about making PARS approval server-side

Okay, manual fallback sucks :-/

marc: I'm still sceptical that we will get fast adoption of a server side feature, though. Just consider the OMEMO situation for non roster conversations

Ge0rG, but rolling out an easy-xmpp feature which has some fallback scenarios just confuses users IMO

marc: so I had to decide whether to have the manual fallback when the inviting client is offline or to have manual fallback until all server operators have rolled out a module that hasn't been written yet.

Ge0rG, and that's why I'm inviting "my" users to "my" server ;)

marc: maybe your users are smart enough to understand what happens if their client is suddenly asking them to choose an account for every single new conversation.

marc: I'm writing protocol for the general case, and let me tell you that multi account is always a UX nightmare

Ge0rG, don't get the "choose an account for every single conversation" hint

Ge0rG, what I'm saying is that if we implement user-invitation (which is server-side) we shouldn't use a XEP which is client-side and has problems with multiple clients

It should require/implement server-side PARS as well

marc: I'm all for server - side PARS, and the inviter should use that if it's available. But I'm realistic, and so far there are zero servers supporting it

marc: client side PARS, on the other hand, is already working for thousands of users

Ge0rG, yes and I don't say that it is useless but it doesn't fit my "easy-xmpp" understanding

User invitation should be always the same workflow for end-users

marc: most people have an always on mobile client, and I'm sure that most PARS invitations will happen in person. You are describing a corner case that I'm well aware of, and I've chosen the trade-off I consider most suitable for the reality of federated xmpp

marc: I agree.

marc: now tell me how to solve this problem?

Ge0rG, user-invitation XEP must implement server-side PARS

"always use my server" is not a solution because it breaks federation and comes with significant transition cost

Because we have to store an invitation token anyway

Ge0rG, oh you mean this problem

marc: and how are you going to roll this out to all servers?

marc: I'm talking about PARS only now

Solution: Public XMPP server list with high requirements regarding supported XEPs

marc: that will not fix existing servers

and existing users

Ge0rG, correct

marc: so it's not a solution

If a server operator don't want to upgrade features we can not solve it...

marc: we can easily add support for server side token generation to PARS, eg using your proposed protocol

we can if there’s a client-side fallback

The solution can not be to implement everything on client side ;)

marc: except that I have a client side solution working in the 90% case.

Existing users on a bad server will change to other services if "basic" features don't work

marc, no

Ge0rG, 90 % coverage is not enough for nice UX like for WhatsApp/...

marc: and you propose a perfect solution that will work for maybe 20% of users, once implemented and rolled out

marc [10:53]: > Existing users on a bad server will change to other services if "basic" features don't work Now THIS is really bad for UX, because people will change to WhatsApp instead

Ge0rG, there are a lot of feature which require server-side support

It is _not_ a solution to build workarounds on client side IMO

Ge0rG, ha, that’s what I was going to say

marc, I think for robustness, a protocol which can work in both cases would be neat

marc: please pretty please read up the PARS thread on standards@. You are repeating arguments from a year ago

Ge0rG, We don't need to repeat the discussion ;)

I'm out, got some appointments to make.

marc: then provide new arguments to convince me. On standards@

good luck

No, that would take too much time ;)

marc, discussion on standards@ is vtial

discussion here in xsf@ is transient and will get lost

jonasw, to me it quite obvious that the whole XMPP thing doesn't work if we have good server support

This problem needs to be fixed

*"we don’t have good server support" you mean?

I think we can blame MySQL

right, Zash? ^

And if server operators don't want to upgrade, users must change to better servers which have feature which a "standard" nowadays

except that changing servers is a huge PITA

jonasw, there is no other solution for some features

"You want to share picture in a group chat? Sorry, that's not supported by your server but you can send the picture to each individual contact via Jingle!!1! Have a nice day"

Ge0rG, actually, it might not be the worst thing if PARS requires server support. Prevents new people from flocking to unmaintained servers.

marc: except that users won't be able to find out (or care) that it's their server's fault. They will blame xmpp and just move to FaceApp.

or they might not understand that they can even switch servers

marc: ever tried to migrate your roster to a different server?

correct

Ge0rG, no

marc: you should take some time to shoulder surf xmpp novices

Really.

And then come back and ask about enforcing server transition

But if I can share pictures in a group chat I would spend some time on it ;)

Ge0rG, I know a lot of XMPP novices, really

Ge0rG, that's why I know what sucks about XMPP and XMPP clients ;)

And that's why I want an easy user invitation process

Not because I want to invite some pro-users...

Ge0rG, given that jdev@ is flaky, care to elaborate on: 13:58:10 Ge0rG> Zash: csi:active won't help, for multiple reasons 09:51:02 jonasw> Ge0rG, I think Zash meant csn:active, at least that’s what I assumed. Would that help?

> jonasw> or they might not understand that they can even switch servers Strictly speaking they can't. It's a new account with new contacts etc.

Acrynoms with shared prefixes? Meh

csi is not csn :)

Should have just written "an active chat state" or somesuch

also, xmpp.net reaches its resurrection

Dun dun DUN

we might wanna import Holgers database

Wut, one second I could see Zash's avatar, and the next second it was gone. And now it's back. Conversations?!

maybe zash left for a second?

Zash you can't do that to me

My server was restarted

Nonetheless, the client doesn't need the contact to always be online right?

Or maybe that's a feature

I guess it’s a feature

But then I can't differentiate with people with no avatars

Or people I can't see the avatar

153 quirk probably

Can't know the avatar hash without presence

Cache until next presence?

now I can’t stop playing with my own xmpp.net instance

jonasw: nice :)

Holger, do you happen to know what’s needed to make xmppoke work with .onion domains?

Is there any hint of SOCKS support in there?

it seems to have worked with .onion before, at least

That and a local Tor instance ought to do it

Ah yes, onions.lua

ah, it assumes a SOCKS at port 9150

let’s do that

jonasw, wouldn't it depend on the machine being able to resolve .onions? and just that

Zash, any clue why conn:receive(5) in line 60 of onions.lua (<https://bitbucket.org/xnyhps/xmppoke/src/fbf8af64f6611b32bbc820a18643333d3459fb28/onions.lua?at=default&fileviewer=file-view-default>) would return nil?

Ah, socks, hmm

now it magically works

timeout, probably

is jabber.org unavailable?

looking for a victim to test? feel free to target zombofant.net

no, conversations warned me that it can't connect.

ah

test takes suspiciously long, too

https://status.conversations.im/

sees it fail too

> Error: Connection failed.

I've left a message for intosi, who's the only one I know administers that domain.

oh

now it's back?

sorted out tor support in xmppoke-docker, and also tested version querying

Guus, it’s been flaky all day

now I realize that jdev@ is at jabber.org :)

I'm thinking of publising vcards and avatars in a specific item of pubsub nodes

vCard4 and 84?

Should one send a delivery receipt if we load a message with a receipt request from MAM?

I tend towards 'nope'

Flow: what about having the MAM archive sending acks?

Ge0rG, hmm possibly worth considering

Except it's not what the sender would expect

Flow, not instantly, first wait if another client of yours has acked the receipt

Ge0rG, Is it

if not you should definitly send one

lovetox, hu? How do you know that another client acked the receipt? Why does it matter?

Flow: in a perfect world, mam would contain the acks as well

becauise the receipt is in mam

> An entity MUST NOT send an ack message when a user views messages that have been archived or stored on the client or the server (e.g., via Message Archiving (XEP-0136) [8]), only when first receiving the message.

(XEP-0184)

Ge0rG, right, in an perfect world, but you can not count on it

jonasw, hmm that 'MUST' feels to strong here

not my idea

:)

jonasw, that does not touch the case in my opinion

lovetox, I agree

I'm sending acks to archive messages, because I care about ux

as i said, only if another client didnt ack the message already

I think querying the MAM for catch-up counts as "first receiving"

this is specifically not "user views messages that have been archived" ✏

jonasw: you can't know if you are the first one

jonasw, I see a slight issue here that you may end up ack'ing the wrong message because the sender does re-use IDs

Ge0rG, you know when you, as the client entity, first receive a message.

Flow, that’s the senders fault

Right

can you blame him for standard compliant behavior?

I will always blame people who don’t use strong random numbers for message IDs :)

if he wants receipts he should care about IDs

Flow: you can blame them for incorrectly applying acks

Ge0rG, blame whom?

Flow: the sending entity

ok, you would be a hell of a laywer

Note to self for XMPP 2.0: The server should always assign unique IDs to outgoing stanzas and tell the ID the client. A MAM-like mechaninsm is possibly mandatory. And message 'type' names are not named after use-cases but after their routing semantics

Flow: I'm sure that 0184 mandates sufficient randomness

Ge0rG, can't find it

Flow: I want routing semantics decoupled from message type

I'm on mobile right now

Ge0rG, 184 does not require any entropy

it only reqiures that the id attribute i sset

Somebody should fix it then

#fixing-a-draft

> Warning: file_get_contents("http://xmppoke:1337"): failed to open stream: No such file or directory in /var/www/html/submit.php on line 42

Hmm

Zash, ah, iteam is working on it again?

that was a known problem a few hours ago, then guus had to leave and reversed the proxy to show the static redirection again.

Duno, doesn't look like a redirect atm

yeah

I guess somebody is working on it

working on it right now

should perhaps maybe work now.

testing :)

throwing a few domains from the public server directory into it

Yeah, I'm running a client and a server test too

ok, off to feed the kids

looks good so far

thanks all

I'll also be leaving in ~1hour

if we need to roll back, someone will need to tell me before then.

so give it a couple of tries please :)

I’ll post to members@

but, this looks pretty good so far. Thanks for reviving it, jonasw!

:)

jonasw: it'd be good to verify that it a) automatically deploys an updated dockerhub repo, and b) doesn't wipe all old data when it does.

perhaps you can invoke a change?

Guus, on which repository?

it checks all three

okay

every 5 minutes

will push an empty commit or something

something that's visible, perhaps?

mmm

so that we can check if it actually got updated

seems ok

yeah, first results are pouring in

nice!

we should avoid updates on the xmppoke thing itself though

how's that?

it kills the pokers

Is this an XSF project maintained by the iteam now?

Guus, build queued

I got to run

cool, tx

Guus, Bad gateway?

Guus, I think the autopull went wrong

or it takes waaay too long

yah, bad gateway

blame Link Mauve?

always

Same here. Link Mauve :@

I manually triggered what cron does - now it runs again

unsure what went wrong

logs?

it also seems to have killed all tests which were in progress

yeah, upon redeploy it kills all docker instances and restart each

no time to look at logs - need to run now.

> yeah, upon redeploy it kills all docker instances and restart each I love Docker more and more every day

doesn’t it kill the containers rather than docker itself?

containers are supposed to be as stateless as possible, so it makes sense to kill them on redeploy

I wouldn't be very sad if someone killed Docker.

it’s a useful tool

It's another level of abstraction added to our already overly complex tech stack

Ge0rG, s/docker/container solutions/ ?

pep.: Yeah, all of them.

What about VMs

runc (or even containerd) itself is quite a bit less complex than the docker ecosystem

mathieui, the issue is that the poke processes which are in progress get killed

those are stateful

the best we could do is probably look into the DB and re-start all pokes which are marked as "running"

a bit of a pain

jonasw, but do you need the poke upgrades?

jonasw: I prefer a stop running new jobs and wait for existing ones to finish approach

To be fair for this who really cares

Is that going to be updated so regularly that it matters...

How are you killing docker? You can tell it to send a signal so you can do graceful shutdown

docker kill --signal=SIGINT or something to that effect

SamWhited, I guess that’s left to docker-compose

it updates the compose stack and by doing so it kills the previous container and spins a new one ✏

docker-compose sends a sigterm already, you just have to respect that IIRC

We use docker-compose heavily at work and everything gracefully restarts fine; I don't remember having to do anything special other than handle signals

can I get some upvotes on HN? https://news.ycombinator.com/item?id=15892761

daniel: I've heard you need to go through the "new items" page for an upvote to count properly...

maybe they just tell you that so you don't use your army of sock puppet

Maybe, yes.

But I've upvoted now

thanks

I like how it's called a Jabber / XMPP client...

and not a "Conversations client, compatible with and certified by the Conversations network"?

Approved by the Conversations Council of Elders?

> avoids using GCM

Is it legitimate to offer a "Show password" field on MUC passwords?

SamWhited, a graceful shutdown for poke would take up to 15 minutes

Ge0rG: what are you thinking on?

SouL: I've replaced the "Repeat passwords" fields for account config/creation with a "[X] Show password" checkbox. Now I ponder if I should add that checkbox to MUC dialogs

MUCs that have a password

Ge0rG: Why not? I think you did pretty well going in that direction.

right now, it's not possible to see a MUC password at all

the other dialogs only allow seeing a password you just enetered, not one that has been there already

Just to tell you a secret, I'm more than glad that Firefox allows me to check all saved passwords :)

I'm fucked if someone steals my laptop though

But it is a feature I would really like to have

SouL, you have a master password hopefully right?

And it makes sense, if you want to invite someone to a MUC you have been always joined but you don't remember that password.

pep.: I also hope

Haha

Can you start a new container without killing the old one? And like, redirect stuff to the new one until the old one is doen with its things

I don't know if docker itself can do that.

I mean make the port bound to a new container

jonasw: is that a problem?

SamWhited, can you have docker wait that long for a process to come down?

pep.: I think it does by default if you use docker-compose or docker kill

Ok

Ge0rG: I get kicked out from xmpp@y.i since the last day or so. Says my JID is malformed and then gives me code 110. Never seen that before. Did you change something?

> ThurahT has left the room (Kicked: jid malformed)

ThurahT: I believe it's because someone has the nick "uc 🕴🏻" there, and your server doesn't like that

So, unicode madness. The proper reaction is to lie down and cry.

haha, wat. My server is jabber.org..

Unicode Madness!

indeed..

guess that is the final nail in the coffin for using j.o with the spam and all. I'll remake my bookmarks with another server.

ThurahT: come to yax.im - we have World Class spam protection

jonasw, I get "Error: test failed." :(

will do

(xmpp.net)

Certificate score and protocol score seem to be completed. Then it continues loading, waited an hour, refreshed and "Error: Test failed."