Wizzup | freemangordon: ah yet this is the user_dir in tp-haze's src/main.c, I wonder if this can or should be persistent ultimately | 00:11 |
---|---|---|
Wizzup | freemangordon: also /var/tmp is not cleaned up it looks like, I have many, many tp-haze dirs there | 01:06 |
Wizzup | 59 so far | 01:06 |
Wizzup | at least not always | 02:02 |
freemangordon | Wizzup: https://gitlab.freedesktop.org/xorg/xserver/-/commit/5a549c957a873bd44ab351e627828905ee7dbf18 | 07:42 |
freemangordon | however, this does not help me answer my question - how to properly stop xorg on shutdown | 07:45 |
freemangordon | uvos: ^^^ any idea? | 07:46 |
Wizzup | freemangordon: can't you just send it a signal? | 10:23 |
Wizzup | freemangordon: regarding the user_dir in tp, if we have jabber with omemo keys, that need manual trust marking, or MAM management in xmpp, where do you suggest we store this? | 10:29 |
Wizzup | I can change the tdlib database dir for now to something else in the code, so it won't end up in purple, but this will be a problem for other protocols too | 10:29 |
freemangordon | Wizzup: TP supports AccountStorage or something like that | 10:36 |
freemangordon | also, I am sure libpurple supports something like that | 10:36 |
freemangordon | or it could be just accoutn parameter | 10:36 |
freemangordon | plugin implementing its own storage does not seem proper to me | 10:37 |
freemangordon | https://people.freedesktop.org/~danni/telepathy-spec-voicemail/spec/Account_Interface_Storage.html | 10:38 |
Wizzup | freemangordon: so this could contain a dir to store stuff in? | 10:38 |
freemangordon | no idea :) | 10:39 |
Wizzup | I'm going to bet that likely there is not a way to do this currently | 10:39 |
freemangordon | https://telepathy.freedesktop.org/doc/telepathy-glib/telepathy-glib-account.html#tp-account-get-storage-specific-information-async | 10:39 |
freemangordon | Wizzup: https://telepathy.freedesktop.org/spec/Account_Interface_Storage.html | 10:41 |
freemangordon | if you can grok, please share :) | 10:41 |
Wizzup | I think this just limits what you can do through the account interface | 10:41 |
Wizzup | I also see a bi somewhere that says 'the auth is not stored in the cm' | 10:42 |
Wizzup | https://telepathy.freedesktop.org/spec/Connection_Manager_Interface_Account_Storage.html | 10:42 |
Wizzup | Credentials_Stored (1) The associated account has its authentication credentials (password) stored in the connection manager | 10:42 |
Wizzup | so if that flag is not set, then the cn can't manage the auth | 10:42 |
freemangordon | Wizzup: also, I still don;t understand what exactly this plugin keeps out of the account | 10:42 |
freemangordon | oauth toke *is* kind of password | 10:42 |
Wizzup | freemangordon: telegram is implemented using a foss library called tdlib, and it has its own database storage, keeps track of what message was last seen by the client/device, and it keeps encryption/auth keys | 10:43 |
Wizzup | there is no password at all, and these things MUST persist | 10:43 |
freemangordon | but that' | 10:43 |
freemangordon | s not TP/pidgin's fault, no? | 10:43 |
Wizzup | or you have to scan a qr code every time you lose interface, or get a code on sms and enter it | 10:43 |
Wizzup | pidgin has no problems with this since it doesn't wipe it's own config | 10:43 |
Wizzup | only tp-haze does this | 10:43 |
freemangordon | sure, but that's implementation detail | 10:43 |
Wizzup | ok, what about everything else that needs to be stored/saved? | 10:44 |
freemangordon | it can be saved as account proprty | 10:44 |
Wizzup | device-specific keys (given how signal, whatsapp, telegram, xmpp omemo too) works | 10:44 |
Wizzup | as a property, all these keys, potential binary data, etc? | 10:44 |
freemangordon | yes | 10:44 |
Wizzup | in the .cfg file of connection manager? :D | 10:44 |
freemangordon | TP has no issue whatsoever with custom properties | 10:44 |
freemangordon | yes | 10:44 |
Wizzup | I think maybe you want to rethink this | 10:44 |
freemangordon | what's the problem? | 10:44 |
freemangordon | I don;t get it | 10:45 |
Wizzup | params are set by the user, not by the program | 10:45 |
Wizzup | they are input, not storage | 10:45 |
Wizzup | freemangordon: you want 500x 4096 bit rsa kes base64 encoded in accounts.cfg? | 10:45 |
freemangordon | no, I want them in the keystore | 10:45 |
freemangordon | because they belong there | 10:45 |
Wizzup | what keystore? | 10:45 |
freemangordon | user's | 10:45 |
Wizzup | let me see what fremantle's skype plugin does | 10:45 |
freemangordon | no | 10:45 |
freemangordon | wait | 10:45 |
Wizzup | I bet that it has it's own .config or .local/share or so | 10:45 |
freemangordon | that's where empathy stores passwords/keys/etc | 10:46 |
freemangordon | accounts-ui is old-fashioned and we shall fix that someday | 10:46 |
Wizzup | the tdlib that everyone uses for telegram needs a directory to function | 10:46 |
freemangordon | as in - we keep passwords in the .cfg | 10:46 |
Wizzup | where it stores data | 10:46 |
Wizzup | there's no way around that | 10:46 |
Wizzup | unless we just don't support it, or fork it | 10:47 |
freemangordon | well, then it should have a way to set that dir | 10:47 |
Wizzup | it does, and we set it to the purple runtime dir + tdlib | 10:47 |
Wizzup | well, the current plugin does | 10:47 |
Wizzup | and haze makes a new runtime dir and nukes it | 10:47 |
Wizzup | so I can change it to say ~/.local/share/tdlib or so | 10:48 |
freemangordon | ok | 10:48 |
Wizzup | and then pidgin and telepathy-haze will share the directory | 10:48 |
Wizzup | sorry if that wasn't clear | 10:48 |
Wizzup | I do agree that if we go for gabble, we might want to see if we can store certain things in the keyring/keystore | 10:48 |
freemangordon | no, we must do it | 10:48 |
freemangordon | not only for gabble | 10:49 |
freemangordon | now we store passworkds in clear form | 10:49 |
freemangordon | that's bad :) | 10:49 |
Wizzup | yes, that's a different story/problem I think | 10:49 |
freemangordon | well, to me it is more or less the same, when it comes to RSA keys etc | 10:53 |
freemangordon | the same goes for oauth | 10:54 |
freemangordon | Wizzup: also, you should not change haze work dir to workaround tdlib issues | 10:56 |
freemangordon | if tdlib has a way to set its work dir - that's another story | 10:56 |
Wizzup | freemangordon: yes, that is what I said | 10:57 |
freemangordon | ok | 10:58 |
Wizzup | freemangordon: well for many of these you're storing public keys of contacts | 11:00 |
Wizzup | I don't know if those go into your own keystore | 11:01 |
Wizzup | or like I said before, downloading messages per contact since the last message you saw, that also needs storage | 11:01 |
Wizzup | and the tp plugins will need this data somehow | 11:01 |
Wizzup | but non-haze plugins don't have this problem, they can just write whereever | 11:01 |
freemangordon | that's not TP job (storing messages logs) | 11:01 |
Wizzup | this is not a message log | 11:02 |
freemangordon | "downloading messages per contact since the last message you saw, that also needs storage" | 11:02 |
freemangordon | what is this? | 11:02 |
Wizzup | this is the state of your account/device that needs to be kept in sync with the server | 11:02 |
freemangordon | and how is that different from "message log"? | 11:02 |
freemangordon | besides the wording that is | 11:03 |
Wizzup | because what you need to sync with the server isn't just the last few messages, but probably specific ids and other stuff, and you need to *provide* that to the server I imagine | 11:03 |
Wizzup | when you connect | 11:03 |
Wizzup | so you tell me how the tp plugins get access to that data | 11:03 |
Wizzup | in any case, we'll run into this I think when we actually implement MAM and such | 11:03 |
Wizzup | https://xmpp.org/extensions/xep-0313.html | 11:04 |
Wizzup | so here we will need to keep track of the jids I think, for example | 11:05 |
Wizzup | I am not sure if rtcom allows for this currently, but it will be different for other protocols | 11:05 |
Wizzup | tdlib 'solves' this with its user dir | 11:05 |
Wizzup | I'm just expecting we'll have to make some changes to tp ultimately, but that's fine, we don't need that now | 11:06 |
freemangordon | TP already supports that, AFAIK | 11:07 |
freemangordon | see https://telepathy.freedesktop.org/doc/telepathy-glib/TpMessage.html#tp-message-get-token | 11:07 |
Wizzup | it needs to be passed back to the plugin | 11:08 |
Wizzup | to actually fetch the relevant info | 11:08 |
freemangordon | sure | 11:08 |
Wizzup | and trust me, this was maybe designed with some of xmpp in mind, but definitely not with all the new hipster/fancy centralised protocols that people use :) | 11:09 |
Wizzup | in the case of telegram I think we're 'lucky' because tdlib handles all of this transparently | 11:09 |
freemangordon | I understand that | 11:09 |
Wizzup | so you just get the new messages since you last signed in | 11:10 |
freemangordon | but I am almost sure TP already supports that somehow | 11:10 |
freemangordon | we just have to find how | 11:10 |
Wizzup | ok, I am not so sure, since how can telepathy-gabble tell the server which message it has last seen when it has no storage? | 11:10 |
freemangordon | trying to find | 11:12 |
freemangordon | to me it should be some channel interface | 11:14 |
freemangordon | but I cannot find suitable | 11:14 |
freemangordon | Wizzup: BTW, see this https://telepathy.freedesktop.org/spec/Channel_Interface_Credentials_Storage.html | 11:14 |
Wizzup | yeah | 11:16 |
Wizzup | freemangordon: heh apparmor enforces haze to not be able to read ~/.local/share/tdlib :) | 12:50 |
freemangordon | kind of makes sense | 12:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!