boost, reply, etc buttons and menu items don't work with gotosocial or mastodon

[albertotirla]

background

I'm one of the administrators of a go to social instance. Although I'm not a windows user myself, some of my users are, and they wanted to use this client, because it's accessible and one of the few which aren't web based.

At first, due to the not so great handling of exceptions, twblue was crashing outright when it was trying to query the conversations endpoint and others, because gts didn't implement that and still doesn't. So then, what happened is that I opened an issue in their repository about it, and they fixed that by stubbing the endpoint, so now twblue runs and loads toots.

The problem is though, that the boosting and replying problem described below happened. Since I didn't use the program directly, I had to go through the person doing so, obtain logs and so on, which made it take longer in the end, but such are things

After long debugging sessions with the people in the go to social help channels, as well as other kinds of help, I was able to nerrow down in what circumstances boosting and replying doesn't work, hint, it's not all the time, which means that part could still contain twitter code, or there might be a disconnect there between the UI and the functionality.

steps to reproduce

• open twblue
• log in with an account on a mastodon or go to social instance
• use the buttons next to the post list

expected behaviour

boosting, replying, etc should work from wherever they are activated, including the buttons next to the post list and the context menu items on a post

actual behaviour

Neither boosting, nor replying works with the buttons next to the posts list or the ones in the context menu. Further, it appears to produce errors in the log

twblue version

latest released, according to the website

[juanreina921]

logs.zip
I am the user of TwBlue and I can afferm that the issue is here as well. I have attached a log so you can take a look.

[Arfs6]

Thank you for opening an issue for this.
From the logs, it seems you're using version 2024.01.05.
I think the problem is from the mastodon-like api goto social has. Perhaps an object might be missing or the location has changed.
Anyways, I'd dig deeper on this when I have time. I might need a goto social account.

[manuelcortez]

Hi, this should be already fixed on commit 36420d6. I think I'll fix a few issues with our translation service and will post a new release in the coming days so this and other fixes could be available for users.

[Arfs6]

@manuelcortez That was what I thought at first, but I think it requires more investigation. The commit you linked to is part of the TWBlue version the bug was encountered in.
Furthermore, the log file @juanreina921 shared has two errors showing TWBlue is expecting some values and it couldn't find it.
I'd suggest giving this a second look.

[albertotirla]

if you're refering to the no attribute error, with the object that has to have a visibility property, that's an error in mastodon too, according to another user. The conversations and mutes API not being available crashing twblue is an unhandled exception case, and can be fixed by doing so, but that's already stubbed by go to social with an empty object, so no longer a problem. Also, the streams endpoint isn't supported by gts, they only support the newer websocket streamming API introduced by mastodon, so yeah. I know twblue is trying to use that endpoint because I see it in my server logs, periodically trying and of course getting a 404.

[manuelcortez]

Hi @albertotirla, do you know if there is a way to detect if we are communicating against goTosocial's API or not? I'd like to know this in advance so we can modify TWBlue's buffers to not attempt to call missing endpoints. As far as i have read this is not possible but I am not sure.

[manuelcortez]

Nevermind, it seems we can query /nodeinfo/2.0 to retrieve which software we are communicating with. that's all what I need :)

[albertotirla]

yes, as you discovered, like any fediverse software I know of, this is using nodeinfo as well. However, the better course of action I would recommend is handling the exceptions with try...except, where except is mostly just logging with the warn level and not loading the buffer. But yeah, I wonder why the buttons and the context menu items don't work, while the keyboard shortcuts do

[manuelcortez]

I have been thinking in creating a new session to handle GotoSocial's differences against the official mastodon API. That would allow us to identify the kind of social network we are interacting with, and change our calls accordingly. That would give us several benefits IMO:

• this can scale up: Later we might add official support for other activity pub software with Mastodon derived sessions that might be chosen during account authorisation based in what nodeinfo returns. Every derived session might need to handle certain things in a different way than Mastodon, or even have other endpoints available or streaming methods such as websockets. This can open up support for Pleroma, Plume, etc.
• easyness: As I can see, we don't need to change many things in our GoTosocial compatible session to make it working. We might have mastodon as the reference session and make inherited classes to change what is not available or to extend our original Mastodon session.
• Clean: this would be cleaner than, for example, handling exceptions for this and that platform, especially if we plan to add official support for more platforms later.
• Transparent: the GoToSocial Session, or mastodon's, or whatever else activity pub related session will be selected automatically by TWBlue right after the user session is created and authorised. So this will not change anything for people, but internally TWBlue would be capable of handling everything in a platform by platform case.

[albertotirla]

yep, that could work, I think. The only issue is that, depending on the kind of software you want to be able to use this with, you might have to interact with an API which isn't mastodon like at all, but that might be out of scope, then it's fine to ignore such cases. Also, speaking of go to social differences, for now at least, the way you do filters is using the v1 for that endpoint, because latest is currently not implemented. This could be beneficial for people who have their accounts on older mastodon instances as well, but again that might be a non-goal, which is also fine, as long as it's established that such things are generally non-goals.

[manuelcortez]

I will close this issue now, as it seems after initial GoTosocial compatible session was added those issues no longer exists and users can interact with posts from the GUI aswell. I'll keep improving support for our Gts compatible session in the near future. Feel free to open new issues if you find or get reports about things not working.