SUMMARY Accounts are not persisting through Tokodon being closed and then reopened. When reopening Tokodon after closing it, or after a reboot, you are asked to enter your account information again. Notes: I tried this with both a single account and with two accounts signed in at the same time. The results were the same. After logging in two accounts, restarting the software, and then logging into one of the accounts again to get to the actual content, the second account is not there. I am thinking this means that the accounts aren't being saved at all and that this isn't just a visual error. STEPS TO REPRODUCE 1. Launch Tokodon and add an account 2. Completely close Tokodon or reboot the PC 3. Open Tokodon, at which point you will be asked to log in to an account OBSERVED RESULT Tokodon does not open to your accounts after being logged in after being restarted. EXPECTED RESULT I would expect that you should not have to log into your account every time you reboot the PC or restart the software. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux Mint 21.2 Cinnamon Cinnamon Version: 5.8.4 Linux Kernal: 5.15.0-78-generic ADDITIONAL INFORMATION System: Kernel: 5.15.0-78-generic x86_64 bits: 64 compiler: gcc v: 11.3.0 Desktop: Cinnamon 5.8.4 tk: GTK 3.24.33 wm: muffin dm: LightDM Distro: Linux Mint 21.2 Victoria base: Ubuntu 22.04 jammy Machine: Type: Desktop Mobo: ASRock model: X570 Pro4 serial: <superuser required> UEFI: American Megatrends v: P2.30 date: 01/13/2020 CPU: Info: 8-core model: AMD Ryzen 7 3700X bits: 64 type: MT MCP arch: Zen 2 rev: 0 cache: L1: 512 KiB L2: 4 MiB L3: 32 MiB Speed (MHz): avg: 4017 high: 4105 min/max: 2200/3600 boost: enabled cores: 1: 4010 2: 4035 3: 4012 4: 4046 5: 4075 6: 4087 7: 4061 8: 3887 9: 4050 10: 3971 11: 3988 12: 4006 13: 3960 14: 4105 15: 3966 16: 4020 bogomips: 115202 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm Graphics: Device-1: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] vendor: Sapphire driver: amdgpu v: kernel pcie: speed: 16 GT/s lanes: 16 ports: active: DP-1,HDMI-A-1 empty: DP-2,DP-3 bus-ID: 05:00.0 chip-ID: 1002:731f Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa gpu: amdgpu display-ID: :0 screens: 1 Screen-1: 0 s-res: 3840x1080 s-dpi: 96 Monitor-1: DisplayPort-0 mapped: DP-1 pos: right model: VG278 res: 1920x1080 dpi: 82 diag: 686mm (27") Monitor-2: HDMI-A-0 mapped: HDMI-A-1 pos: primary,left model: VG27VQ res: 1920x1080 dpi: 82 diag: 686mm (27") OpenGL: renderer: AMD Radeon RX 5700 XT (navi10 LLVM 15.0.7 DRM 3.42 5.15.0-78-generic) v: 4.6 Mesa 22.2.5-0ubuntu0.1~22.04.3 direct render: Yes Audio: Device-1: AMD Navi 10 HDMI Audio driver: snd_hda_intel v: kernel pcie: speed: 16 GT/s lanes: 16 bus-ID: 05:00.1 chip-ID: 1002:ab38 Device-2: AMD Starship/Matisse HD Audio vendor: ASRock driver: snd_hda_intel v: kernel pcie: speed: 16 GT/s lanes: 16 bus-ID: 0b:00.4 chip-ID: 1022:1487 Device-3: Logitech PRO X Wireless Gaming Headset type: USB driver: hid-generic,snd-usb-audio,usbhid bus-ID: 3-2:5 chip-ID: 046d:0aba Sound Server-1: ALSA v: k5.15.0-78-generic running: yes Sound Server-2: PulseAudio v: 15.99.1 running: yes Sound Server-3: PipeWire v: 0.3.48 running: yes Network: Device-1: Intel I211 Gigabit Network vendor: ASRock driver: igb v: kernel pcie: speed: 2.5 GT/s lanes: 1 port: e000 bus-ID: 06:00.0 chip-ID: 8086:1539 IF: enp6s0 state: up speed: 1000 Mbps duplex: full mac: <filter> IF-ID-1: br-96c1b1b46859 state: up speed: 10000 Mbps duplex: unknown mac: <filter> IF-ID-2: docker0 state: down mac: <filter> IF-ID-3: veth4b908b9 state: up speed: 10000 Mbps duplex: full mac: <filter> Drives: Local Storage: total: 2.91 TiB used: 136.35 GiB (4.6%) ID-1: /dev/sda vendor: Samsung model: SSD 870 QVO 2TB size: 1.82 TiB speed: 6.0 Gb/s serial: <filter> ID-2: /dev/sdb vendor: SanDisk model: SDSSDH3 1T02 size: 953.87 GiB speed: 6.0 Gb/s serial: <filter> ID-3: /dev/sdc vendor: Corsair model: Corsair Force 3 SSD size: 167.68 GiB speed: 6.0 Gb/s serial: <filter> Partition: ID-1: / size: 163.5 GiB used: 136.32 GiB (83.4%) fs: ext4 dev: /dev/sdc2 ID-2: /boot/efi size: 511 MiB used: 31.2 MiB (6.1%) fs: vfat dev: /dev/sdc1 Swap: ID-1: swap-1 type: file size: 2 GiB used: 0 KiB (0.0%) priority: -2 file: /swapfile Sensors: System Temperatures: cpu: N/A mobo: N/A gpu: amdgpu temp: 57.0 C mem: 66.0 C Fan Speeds (RPM): N/A gpu: amdgpu fan: 797 Repos: Packages: 3180 apt: 3160 flatpak: 20 No active apt repos in: /etc/apt/sources.list Active apt repos in: /etc/apt/sources.list.d/docker.list 1: deb [arch=amd64 signed-by=/usr/share/keyrings/docker.gpg] https: //download.docker.com/linux/ubuntu jammy stable Active apt repos in: /etc/apt/sources.list.d/element-io.list 1: deb [signed-by=/usr/share/keyrings/element-io-archive-keyring.gpg] https: //packages.element.io/debian/ default main Active apt repos in: /etc/apt/sources.list.d/microsoft-edge.list 1: deb [arch=amd64] https: //packages.microsoft.com/repos/edge/ stable main Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 1: deb http: //packages.linuxmint.com victoria main upstream import backport 2: deb http: //archive.ubuntu.com/ubuntu jammy main restricted universe multiverse 3: deb http: //archive.ubuntu.com/ubuntu jammy-updates main restricted universe multiverse 4: deb http: //archive.ubuntu.com/ubuntu jammy-backports main restricted universe multiverse 5: deb http: //security.ubuntu.com/ubuntu/ jammy-security main restricted universe multiverse Active apt repos in: /etc/apt/sources.list.d/protonvpn-stable.list 1: deb [arch="all", signed-by=/usr/share/keyrings/protonvpn-stable-archive-keyring.gpg] https: //repo.protonvpn.com/debian stable main Active apt repos in: /etc/apt/sources.list.d/signal-xenial.list 1: deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https: //updates.signal.org/desktop/apt xenial main Active apt repos in: /etc/apt/sources.list.d/slack.list 1: deb https: //packagecloud.io/slacktechnologies/slack/debian/ jessie main Active apt repos in: /etc/apt/sources.list.d/jellyfin.sources 1: deb [arch=amd64] https: //repo.jellyfin.org/ubuntu jammy main Active apt repos in: /etc/apt/sources.list.d/winehq-jammy.sources 1: deb [arch=amd64 i386] https: //dl.winehq.org/wine-builds/ubuntu jammy main Info: Processes: 430 Uptime: 1h 24m Memory: 31.27 GiB used: 6.66 GiB (21.3%) Init: systemd v: 249 runlevel: 5 Compilers: gcc: 11.3.0 alt: 11/12 Client: Cinnamon v: 5.8.4 inxi: 3.3.13
You can confirm this is 23.08 right? I would check if the account information is saved on disk, which would be under /home/<your username>/.local/share/KDE/tokodon/tokodonstaterc. You should see some human readable text, including the instance url and the username. If that exists, I suspect that the password is not being saved in your system keychain correctly. If Tokodon can't read the password, it will throw you back on the login screen which isn't the best UX right now. I'm not sure what Cinnamon uses, do you have GNOME keychain or something similar?
I'll comment on what I see on this box. If I do not log out of Tokodon it stays logged in between reboot's and shutdown's fine. The interesting thing I see here is if I log out the "tokodonstaterc" vanishes from .local/share/KDE/tokodon/ and of course then I have to provide the details get a new token again. Operating System: Fedora Linux 38 KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 KDE Apps 23.08.0 Kernel Version: 6.5.2-301.fc38.x86_64 (64-bit) Graphics Platform: Wayland
That's to be expected, and what software using KConfigXT does (which is a lot of KDE software). If there is no settings set to something non-default, it will remove the config file. You can see this happen with regular Tokodon settings (~/.config/tokodonrc) as well, but there's some state-related things in there still but not from us.
Thanks for the info..
Can you see if you experience this issue still with 23.08.2? I'm restarting my Flatpak here constantly, and can't get it to log out without me explicitly doing so. I suspect that it's asking you to log in again because of an invalid token/other issue, which is something that will be clearer in the next release.
(In reply to Joshua Goins from comment #5) > Can you see if you experience this issue still with 23.08.2? I'm restarting > my Flatpak here constantly, and can't get it to log out without me > explicitly doing so. I suspect that it's asking you to log in again because > of an invalid token/other issue, which is something that will be clearer in > the next release. I'm not sure who this question is for, but FYI it works the same here with 23.08.2 as it did with 23.08.0 details in comment2
Hi, I'm also experiencing this issue. I've reproduced on a AwesomeWM session. If I start kwalletmanager before starting Tokodon, then the account login is saved. Maybe Tokodon should instantiate the wallet manager if anything is found?
(In reply to FiNeX from comment #7) > Hi, I'm also experiencing this issue. I've reproduced on a AwesomeWM > session. If I start kwalletmanager before starting Tokodon, then the account > login is saved. Maybe Tokodon should instantiate the wallet manager if > anything is found? Technically this is not our doing, it's the underlying library called QtKeychain (https://github.com/frankosterfeld/qtkeychain). I would think that having Tokodon starting a wallet manager is problematic, what application would start on something like AwesomeWM? It could a libsecret service, GNOME Keyring, KWallet, etc. I think a solution can be found though, and that would benefit everything that use QtKeychain :-)
Git commit 2b4e90ff2699164a717a98bc52292347317fc9b1 by Joshua Goins. Committed on 13/01/2024 at 21:19. Pushed by redstrate into branch 'master'. Add initial setup flow where required This adds several new pages for "initial setup" in places where this is needed. In some cases, the environment does not have a password service so Tokodon refuses to continue in order to prevent logging in and losing your credentials. On Android, the notifications permission is prompted here too. In the ideal KDE Plasma desktop setup (or GNOME Desktop) there is no setup. Related: bug 477927 M +7 -0 src/CMakeLists.txt M +3 -0 src/config.kcfg A +59 -0 src/content/ui/InitialSetup/SetupNotifications.qml [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)] A +37 -0 src/content/ui/InitialSetup/SetupPassword.qml [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)] A +47 -0 src/content/ui/InitialSetup/SetupWelcome.qml [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)] M +8 -1 src/content/ui/Main.qml A +100 -0 src/utils/initialsetupflow.cpp [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)] A +26 -0 src/utils/initialsetupflow.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)] https://invent.kde.org/network/tokodon/-/commit/2b4e90ff2699164a717a98bc52292347317fc9b1
(In reply to Joshua Goins from comment #8) > (In reply to FiNeX from comment #7) > > Hi, I'm also experiencing this issue. I've reproduced on a AwesomeWM > > session. If I start kwalletmanager before starting Tokodon, then the account > > login is saved. Maybe Tokodon should instantiate the wallet manager if > > anything is found? > > Technically this is not our doing, it's the underlying library called > QtKeychain (https://github.com/frankosterfeld/qtkeychain). I would think > that having Tokodon starting a wallet manager is problematic, what > application would start on something like AwesomeWM? It could a libsecret > service, GNOME Keyring, KWallet, etc. I think a solution can be found > though, and that would benefit everything that use QtKeychain :-) I understand. Maybe there is a way to know which service call? For example when I start Krusader (on a AwesomeWM session) and KWallet is not yet active, it's executed by Krusader itself.
> I understand. Maybe there is a way to know which service call? For example > when I start Krusader (on a AwesomeWM session) and KWallet is not yet > active, it's executed by Krusader itself. I don't think there's a way to do this yet, but this has been a common enough need in applications I work on where I feel like we can add this upstream. In the next version (not 24.02) there's a clearer setup stage where if Tokodon doesn't detect a password service it will refuse to function, to prevent situations like this. If I can put a more specific name of the service it's attempting to contact (Kwallet, GNOME password, etc) then that would be even better :-)