neshtaxmpphi 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
moparisthebestI mean the answer is you configure them however you want
moparisthebestYou 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
moparisthebestpeter: 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
neshtaxmppmoparisthebest: 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
neshtaxmppmoparisthebest: and who is the not federated server...
neshtaxmppmoparisthebest: 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
neshtaxmppmoparisthebest: 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
moparisthebestWhat 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
neshtaxmppWhat 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
edhelasI 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
edhelasThis 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
lovetoxits a bit more work then just encrypting everything
Dave Cridlandhas joined
alacerhas joined
lovetoxthere are elements you dont want to encrypt
edhelasyes :)
lovetoxand these have to be specified :)
lovetoxas daniel often said, there is probably no one against full stanza encryption, just no one did write it up yet
edhelasthat's why I'm saying that we should put a specific tag or namespace for those specific tags
edhelasthe 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
lovetoxfull stanza encryption is specified in 0373 and i think 0200
lovetoxalso a question was, it should be specified what happens if i find a tag inside the encrypted payload, and outside
Fabianhas joined
danielOr what happens if there is a tag outside that influences the inside. For example a message correction tag
lovetoxi think we should probably ignore all outside tags except a certain whitelist
andyhas left
andyhas joined
lovetoxbut 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
lovetoxeme for one
lovetoxits not about client, its about server
lovetoxhints 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.
danielI can only think of stanza and origin id
jonas’or stanza-metadata, hm, yes.
danielEme is only relevant _before_ the decryption
ralphmInstead 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
ralphmHas anyone had a use case like this? If so, how did you solve it?
lskdjfhas left
MattJralphm, I was planning to write an extension for that. MAP (Message Archive Preview) :)
thorstenhas joined
Seve/SouLSounds great
MattJIt seems clients are favouring the per-contact sync, instead of sync-everything
ralphmI could imagine maybe a boolean field in the MAM Data Form that indicates you only want one for each party?
MattJPotentially, yes
Dave Cridlandhas left
marchas left
Dave Cridlandhas joined
ralphmMattJ: indeed. Also in our case, we don't really have a roster
ralphmYou have people on your (phone) contact list, and then other sources of things to talk to, like groups and non-people.
ralphmBy the way, I love the MAP backronym.
MattJ:)
MattJFancy working on the XEP?
ZashI do believe Kev has talked about some kind of summary like this as well
MattJReality 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
Ge0rGIt's much better than the CSI backronym.
ralphmWe 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
lovetoxralphm, do you request the last message for every contact in the roster on start?
lskdjfhas left
lskdjfhas left
lskdjfhas left
lovetoxmy 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
lovetoxso how do you knwo which jids to sync
jonas’lovetox, all
Dave Cridlandhas left
Dave Cridlandhas joined
ZashLast message per contact
lovetoxsince a certain mam-id
lovetoxobviously, otherwise this would be very expensive
ZashThat sounds massively more expensive
ZashKeeping 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
ralphmNo, no roster
ZashYou 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)
lovetoxwhat 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.
ralphmMy 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
Ge0rGjonas’: 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
ZashNo nice things allowed.
Ge0rGralphm: that might explode if you have chatted to many entities. Or if you were bot-flooded.
ralphmlovetox: 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.
ralphmGe0rG: well, you can paginate this too, no?
ralphmGe0rG: or are you worried about the server side complexity of 'the last one' per contact?
lovetoxralphm do you store the messages on the phone?
danielhas left
ralphmlovetox: cache, yes
Ge0rGralphm: both, actually
danielhas joined
lorddavidiiihas left
ralphmbut 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
ralphmjonas’: 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])
Ge0rGor 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
ralphmeh no
Valerianhas left
jonas’do you expect huge phone books?
Ge0rGjonas’: 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
lovetoxif 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
ralphmGe0rG: indeed. I could imagine retrieving the last 7 days of history, but you still want an entry for people you talked to longer ago
ralphmAnd then if you go into one of those chats, you can still backfill that contact
alacerhas joined
Ge0rGralphm: so you are also asking for indefinite storage of all JIDs you had a chat with?
ralphmThe thing is that you don't want a full history sync when you reinstall an app or switched phones or whatever
ralphmGe0rG: 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
ralphmThe 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.
XSF Discussion - 2018-09-18