hi sslh was configured but it log in syslog, it was followed this manual: http://william.shallum.net/random-notes/sslh-configuring-logging-logrotate-and-logwatch and it still log in syslod, sslh was restart and same
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Guushas left
Guushas joined
Guushas left
lhas left
Guushas joined
equilhas left
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
moparisthebesthas joined
moparisthebest
I mean the answer is you configure them however you want
moparisthebest
You need to understand ips and ports and what sslh does though, you aren't going to find a copy paste Tut for it
apachhas left
apachhas left
Guushas left
Guushas joined
moparisthebest
peter: nice so 'I'm going to generalize about all federated systems then come up with one that isn't federated because I haven't considered how to solve those problems in a federated system'
Guushas left
peterhas left
SamWhitedhas left
lhas joined
SamWhitedhas left
SamWhitedhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
apachhas left
apachhas left
peterhas joined
neshtaxmpp
moparisthebest: your tutorial was good... but it suck... simply step by step... and you have to remove , from line 16... Imagine, today you was online... person want install ssllh, he see your tutorial, start scratch in hear... make everything correctly... after some hours to see how to make it work " without step by step he need to lost hime time " and when he run sshl -F /etc/sslh.cfg it will comment " error in line 16 " he will start again scratch head hair and agai other 1 day to configure how to repair the problem. so 2 days to install, configure and run sslhd. but here come true life. what happend if he dont find you moparisthebest... so he has to wait more days... maybe 2 days more until you return... or maybe 1 month... or maybe 1 year... becouse when person dont know how to run somethink. he has to wait untill someone help him... so imagine he has to wait 1 year untill someone or you appear help him. this is 1 year to remove one " simply SHIT , " if he has goodluck he cab wait 1 year, and if he dont habe goodluck it can be 2 years... and more... so for some manual that can work 10 min. he has to wait 1 year or more years... to someone help him. moparisthebest today you can have internet, tomorrow do you know if you are gonna have internet... you can " i pay money " - > piu piu... you can money but when government say no more internet there will be no more internet...
peterhas left
neshtaxmpp
moparisthebest: and who is the not federated server...
neshtaxmpp
moparisthebest: is this some kind of indirect you want my help for federated system. if i can i will help.
jjrhhas left
neshtaxmpphas left
Dave Cridlandhas left
Dave Cridlandhas joined
neshtaxmpp
moparisthebest: sslh is program for linux " unknown if it work in macos " that help peoples with limited ports. all other ports blocked only open 443 and 80 -> only for viewing web sites... sslh enter here and safe peoples... limited port and firewall... have noce day.
Dave Cridlandhas left
Dave Cridlandhas joined
apachhas left
apachhas left
jjrhhas left
lumihas left
alexishas joined
alexishas left
alexishas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
moparisthebesthas left
moparisthebesthas joined
Dave Cridlandhas left
Dave Cridlandhas joined
apachhas left
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Yagizahas joined
moparisthebest
What in the world kind of drunken rant was that
apachhas left
apachhas left
Guushas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
mrdoctorwhohas left
mrdoctorwhohas joined
apachhas left
apachhas left
alacerhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
alacerhas left
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
apachhas left
neshtaxmpp
What in the world kind of drunken rant was that
neshtaxmpphas left
neshtaxmpphas left
apachhas left
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
alacerhas joined
Nekithas joined
thorstenhas left
lorddavidiiihas joined
thorstenhas joined
bearhas left
bearhas left
Zashhas joined
alacerhas left
alacerhas joined
apachhas left
Guushas left
Guushas joined
apachhas left
danielhas left
danielhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
lnjhas joined
alacerhas left
derdanielhas left
derdanielhas joined
alacerhas joined
thorstenhas left
thorstenhas joined
lovetoxhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
alacerhas left
alacerhas joined
moparisthebesthas left
moparisthebesthas joined
j.rhas joined
lnjhas left
apachhas left
alexishas left
Dave Cridlandhas left
Dave Cridlandhas joined
alexishas joined
Dave Cridlandhas left
Dave Cridlandhas joined
alacerhas left
apachhas left
andyhas joined
!xsf_martinhas joined
alacerhas joined
ralphmhas joined
goffihas joined
jjrhhas left
Nekithas joined
apachhas left
Dave Cridlandhas left
Dave Cridlandhas joined
edhelas
I had some though on OMEMO and related metadata, the problem with OMEMO (and other e2ee solutions) is that they are only encrypting the body element. I was wondering if we couldn't also encrypt, using the same key, the other value of the other attributes of the message (by adding a namespace to those elements for example). For SIMS we could then encrypt <media-type>, <name>, <thumbnail cid…>.
jjrhhas left
!xsf_martinhas left
edhelas
This will still leak some "structural metadata" but at least the content should be protected. And it should be fairly easy to implement it in clients (we have to check for the retro compability).
alacerhas left
Dave Cridlandhas left
Dave Cridlandhas joined
Valerianhas joined
Zashhas left
Zashhas joined
alexishas left
alexishas joined
labdsfhas left
jjrhhas left
Dave Cridlandhas left
lovetox
its a bit more work then just encrypting everything
Dave Cridlandhas joined
alacerhas joined
lovetox
there are elements you dont want to encrypt
edhelas
yes :)
lovetox
and these have to be specified :)
lovetox
as daniel often said, there is probably no one against full stanza encryption, just no one did write it up yet
edhelas
that's why I'm saying that we should put a specific tag or namespace for those specific tags
edhelas
the problem with full stanza encryption is that it requires to hack the parser behavior and thing that should be encrypted and things that shoudn't can't be on the sams XML depth anymore
lovetox
full stanza encryption is specified in 0373 and i think 0200
lovetox
also a question was, it should be specified what happens if i find a tag inside the encrypted payload, and outside
Fabianhas joined
daniel
Or what happens if there is a tag outside that influences the inside. For example a message correction tag
lovetox
i think we should probably ignore all outside tags except a certain whitelist
andyhas left
andyhas joined
lovetox
but then the problem is, if new xeps arise we have to update that list
jonas’
I wonder which tags are relevant to clients && must not be encrypted
neshtaxmpphas joined
jonas’has left
lovetox
eme for one
lovetox
its not about client, its about server
lovetox
hints for example
jonas’
sure
jonas’
but the server shouldn’t care about the encrypted payload
jonas’
and the client shouldn’t care about the unencrypted payload (in general)
jonas’
you know where I’m getting at?
daniel
> i think we should probably ignore all outside tags except a certain whitelist
Thats what I proposed years ago
jonas’
i.e. the whitelist will probably be encryption-metadata like EME, and everything else can be ignored by the client.
Instead of retrieving all history from MAM, I'd like to ask the archive the last message for each party I conversed with to build a chronological index, and then progressively retrieve history when going into one of them.
lskdjfhas left
ralphm
Has anyone had a use case like this? If so, how did you solve it?
lskdjfhas left
MattJ
ralphm, I was planning to write an extension for that. MAP (Message Archive Preview) :)
thorstenhas joined
Seve/SouL
Sounds great
MattJ
It seems clients are favouring the per-contact sync, instead of sync-everything
ralphm
I could imagine maybe a boolean field in the MAM Data Form that indicates you only want one for each party?
MattJ
Potentially, yes
Dave Cridlandhas left
marchas left
Dave Cridlandhas joined
ralphm
MattJ: indeed. Also in our case, we don't really have a roster
ralphm
You have people on your (phone) contact list, and then other sources of things to talk to, like groups and non-people.
ralphm
By the way, I love the MAP backronym.
MattJ
:)
MattJ
Fancy working on the XEP?
Zash
I do believe Kev has talked about some kind of summary like this as well
MattJ
Reality is, I probably won't get to it for a couple of weeks at least
alacerhas left
lhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Ge0rG
It's much better than the CSI backronym.
ralphm
We probably are fast-moving on this, but that doesn't mean I can't work on a standard for it and move to that later
marchas joined
lhas left
lhas left
lhas left
j.rhas left
j.rhas joined
alexishas left
alexishas joined
blablahas left
danielhas left
danielhas joined
tahas left
j.rhas left
danielhas left
danielhas joined
lskdjfhas joined
j.rhas joined
lovetox
ralphm, do you request the last message for every contact in the roster on start?
lskdjfhas left
lskdjfhas left
lskdjfhas left
lovetox
my question is about how do you solve the problem that you cannot know what the last conversation was in a multi device env
Dave Cridlandhas left
Dave Cridlandhas joined
lovetox
so how do you knwo which jids to sync
jonas’
lovetox, all
Dave Cridlandhas left
Dave Cridlandhas joined
Zash
Last message per contact
lovetox
since a certain mam-id
lovetox
obviously, otherwise this would be very expensive
Zash
That sounds massively more expensive
Zash
Keeping the last ID per roster entry in a cache seems doable
jonas’
note that ralphm was specifically talking about not really having a roster
danielhas left
danielhas joined
ralphm
No, no roster
Zash
You know I'll cry if you design a thing that requires a SQL RDBM
Ge0rG
`SELECT MAX(uuid),* FROM contacts, messages WHERE contacts.jid = messages.jid;`
jonas’
> MAX(uuid)
lovetox
what does that mean no roster, you talk only to a single jid? because if you have knowledge about more than one jid in your application you have a roster, i dont see how it is relevant if this roster is kept on the server or on the client
jonas’
that’s not how it works.
ralphm
My thinking was that you do a MAM request to get all message history, but instruct it to only return one entry per unique other entity you've contacted (other user, room, whatever)
lskdjfhas joined
Ge0rG
jonas’: stop spoiling my fun
jonas’
lovetox, it is relevant for the server-side MAM implementation whether it knows which JIDs are relevant or whether it has to assume they all are
Zash
No nice things allowed.
Ge0rG
ralphm: that might explode if you have chatted to many entities. Or if you were bot-flooded.
ralphm
lovetox: in our case, instead of a roster, we have a native mobile phone address book, and retrieve matches from the server. Not unlike apps like WhatsApp do.
ralphm
Ge0rG: well, you can paginate this too, no?
ralphm
Ge0rG: or are you worried about the server side complexity of 'the last one' per contact?
lovetox
ralphm do you store the messages on the phone?
danielhas left
ralphm
lovetox: cache, yes
Ge0rG
ralphm: both, actually
danielhas joined
lorddavidiiihas left
ralphm
but you definitely don't want to retrieve all messages at once either, most of the time you only need history for a contact when you start chatting
marchas left
jonas’
ralphm, I’m not sure how many messages you are expecting between reconnects and how many contacts you expect people to have, but if the message load is "regular", you might get less traffic with normal "MAM since last connct" than what you propose
ralphm
jonas’: not on a reinstall
jonas’
because the one is O(number of contacts ever ever spoken to [monotonically increasing]) and the other is O(number of contacts actively sending messages times average message rate per contact times offline time [approximately constant])
Ge0rG
or when you didn't charge your phone for a month.
jonas’
ralphm, okay, that makes sense
jonas’
but on a reinstall, I wouldn’t worry too much and just do a MAM query for each phonebook entry
ralphm
eh no
Valerianhas left
jonas’
do you expect huge phone books?
Ge0rG
jonas’: there is an upper bound due to the typical history age timeout, so you'll only get the contacts you chatted to in the last 14d or so
lovetox
if you have implemented something like that, im very interested how you did it, i try to find a way to backfill the history since a month, and all i can come up is that its not possible without lossing the order of the messages
jonas’
Ge0rG, depends on the history model on the server side, really
ralphm
Ge0rG: indeed. I could imagine retrieving the last 7 days of history, but you still want an entry for people you talked to longer ago
ralphm
And then if you go into one of those chats, you can still backfill that contact
alacerhas joined
Ge0rG
ralphm: so you are also asking for indefinite storage of all JIDs you had a chat with?
ralphm
The thing is that you don't want a full history sync when you reinstall an app or switched phones or whatever
ralphm
Ge0rG: might still be definite, but still different from a contact list. Contact lists change and also you want the chronological order
danielhas left
danielhas joined
lorddavidiiihas joined
ralphm
The server-side complexity of getting a list like this is an implementation detail. It could be part of the storage model, or you can build and cache an index based on the actual full history.