zlacker

>>trms+(OP)
I'm an Anki user, on and off since 10 years or so, but was still confused. If I understood correctly, the entities here are:

- Anki, as set up by dae aka Damien, is like the brand name and desktop implementation with the spaced repetition algorithm

- AnkiWeb is what I thought this hub thing was. It's where you download decks

- AnkiHub is a third party (started by "AnKing", now 35 employees) who sells decks as a monthly subscription and has their content on the deep web (you need to create an account and agree to terms to even see a listing of what's there besides a few featured parts). This is who is getting ownership of the former two. Because they write that Anki will remain open source at its "core", I presume that means that things will, at best, stay stable rather than anything (like AnkiWeb the deck sharing platform) becoming open

- AnkiDroid is a separate open source project (an Android app). The corporation is hiring the main developer, but it's not yet clear to me whether they're just going to get paid to work more on AnkiDroid or if they're also getting other tasks

>>Aachen+cu
> AnkiWeb

Worth noting you don't need to use it. Anki comes with a syncserver implementation for a while now, and there are docker images too. It's worth it for the transfer speeds alone IMO.

Anki is under AGPL too, which has an anti-DRM clause, so many type of enshittification of anki or their addons (e.g. to prevent sharing of their decks) would be unenforceable too.

As such I see no obvious things that would be susceptible to enshittification here.

>>digiow+NC
Aha [0], that is neat.

[0]: https://docs.ankiweb.net/sync-server.html

>>pityJu+rE
I've tried several times before to install syncserver using those pip instructions, on multiple platforms, without success.

>>bangon+yI
The pip instructions are bad. Typical Python things: Non-reproducible, not involving a proper lock file. Cargo instructions seem not much better, since they are only referring to a tag in the git repo. The installation from "package build" leak user and password in shell history.

Overall this doesn't inspire much confidence in how solid and tested the procedure is.

>>zelphi+G62
The page is on GitHub:

https://github.com/ankitects/anki-manual/blob/main/src/sync-...

Full disclaimer - it's a feature which AnkiDroid supports, but isn't one which I use.

>>david_+pv2
I see. I am not claiming, that it is your job to fix that.

On that page though, the same issues are present. The pip install does not make use of any lock file.

    pip install anki

Isn't a command we should be seeing in 2026. Unless it is a one-off experiment setup. There should be proper lock files, not just version numbers, especially in the Python and JS ecosystems this has become less and less acceptable.

    SYNC_USER1=user:pass ~/syncserver/bin/python -m anki.syncserver

Leaks username and password to shell command history. Again, can be fine for a one-off quick hack, but is not a great practice, since the shell command history is not the most secure place to store ones credentials in. This could be easily mitigated by adding leading " " (space), at least in environments I am familiar with, but better would probably be putting the credentials in a config file, so that they never hit the shell command history.

The repo already has a lock file for uv. It would be better to make use of that lock file, when using Python to install. And in fact, when one downloads a release of Anki for desktop and runs it the first time, it does make use of uv, creating a venv, and (unconfirmed) hopefully makes use of the uv lock file.

I see these kinds of issues very frequently in Python projects. As someone, who has previously worked on providing docker images for data science workflows, enabling reproducible research, I am quite sensitive to this. But also I hear from friends, that they are traumatized by Python projects installing things in system python and other shenanigans. In general there seem to be tons of people doing Python projects, who don't have a clear idea of how to make things safe and reproducible, which is giving Python projects in general a bad reputation. All while good solutions to these problems exist and existed for years.