AstraLumaOk, today in #Takahe, thinking about tackling reactions (from the misskey family).
First oddity: firefish.social doesn't like my dev server? Which is exciting.
I guess I'm standing up a firefish server and seeing if I can reproduce?
Ok, so I'm implementing reactions anyway, using test data and test suites.
The semantics I think Misskey/etc use is that everyone gets one like/reaction, like Facebook and Telegram. I prefer many reactions, like Slack and Discord. But if the AP messages come in like the way I suspect, I don't think I can implement that without remote server detection (ie, perform slightly different actions based on the software the remote server is running.)
Thankfully, the existing Takahē schema supports this easily--there's an interaction model used for likes, boosts, voting, etc, and it already has a field for storing extra data (currently only used by voting, but it's meant to be generic).
So I just need to write a dozen tests covering basic, duplicate, overwrite, multiple, delete, etc workflows.
Oh, right, you can interact with posts without following the person.
That seems to work just fine, and I have a pile of test data now.
Huh, can any #LitePub folk link me to the emojireact spec? I'm not easily finding it, but there's references in this code to http://litepub.social/ns#emojireact .
Oh no, while investigating the above, I looked at the Pleroma source.
It appears to use a distinct set of messages, instead of just extending Likes. Which is going to make outbound messages Fun™️. 🙃️
I think I'm going to set that aside for now until I can find an expert or documentation on this.
Note to self: If I want to say `COUNT(col)` in django, that's `values('col').distinct().count()`.
Hm. I pull my work to my server and try it live, and it's not working. Unclear why. It should be able to at least accept and display misskey-style emoji reactions.
But I'm going to save that for tomorrow. I need to make food and get ready for lightsaber class tonight.
Ok, today in #Takahe, gotta dig in and figure out why my well-written and well-tested code doesn't actually work at all when deployed.
I feel like I fell into one of the classic blunders.
Ok, I guess the running service wasn't sufficiently restarted. While I was adding logging, it fixed itself.
Next up: UI.
Like none of my tools work well for this remote server work, and installing remote ones is unnecessarily difficult because of the old version of Debian. The pre-commit hooks are prooving particularly troublesome.
I really need to work on Unholy.
The right order of operations would be:
1. Install pyenv
2. Install the dev versions of the sqlite, ncurses, ffi, readline, and lzma libs
3. Compile Python through pyenv
4. Install pre-commit
5. Have pre-commit install into my repo
6. Pray pre-commit can set up all the tools.
Except that I'm largely discovering this in the reverse order by stubbing my toe on every missing piece.
I think I got everything sorted for incoming misskey-style unicode reactions. Which is a lot of qualifiers, but all my next steps involve digging into other implementations and I'm not feeling up for that just yet.
So I'm going to step away from the computer, and then think about how I'm going to rework my dev container tool, Unholy.
Andrew Godwin@astraluma Welcome to the experience of learning how each server does their own weirdness :)