Ok, 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.

Got UI Sorted!

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.

@astraluma Welcome to the experience of learning how each server does their own weirdness :)
@astraluma you can try this instance, too
@aprl ok, thanks!
@aprl (with all these test accounts, I'm running out of art to use as profile pictures!)
@astraluma this is running iceshrimp tho, a firefish hardfork, but emote api should be the same
@aprl Yeah, I think the LD Schema for reactions is unchanged all the way back to Misskey.
@astraluma not really, we added support for akkoma stuff back in calckey, some things changed, but core compatibility just works, as Tod would say it

@aprl It looks like iceshrimp has the same problem.

On the Takahē end, it was https://github.com/jointakahe/takahe/issues/323 related to hostname handling? Misskey/etc do additional validation around keys that nobody else seems to do.

Misskey accounts unable to follow · Issue #323 · jointakahe/takahe

I have 2 Misskey instances and was able to locate and request to follow both of my accounts, but neither was able to successfully follow back. In Takahē I can see that I am following them and they ...

GitHub
@astraluma yes, you need to properly format for misskey type apps :)
This is activitypub spec, but nobody except misskey cares, we do type checking that should be obvious im afraid, just like how mail servers do such validation
@astraluma the issue is id, context etc needs to be valid :)