@alex Very cool! It should run better on a Pleroma backend, I think.

@alex @realcaseyrollins Giving it some thought, I'm interested in how this will work, actually. You're obviously going to have to compromise on functionality in some places, as far as I know the Mastodon/Twitter style of threading isn't even possible on Pleroma, for example. It uses a format more similar to 4chan, one of the big reasons 3rd party apps like Tusky and Fedilab don't work well for it.

Wouldn't be that big a deal if it were just a couple small instances but I know there are a lot of boomers on Spinster who're going to have a hard time adapting to those kinds of changes, and I assume the plan is to use it there.

Not expecting you to have it all worked out yet, obviously, just throwing out some brain thunks. It seems like more of an undertaking than it struck me as when you announced this yesterday.

@shampoobottle @realcaseyrollins Never heard of that before. I think Pleroma implements all the same API endpoints so it should theoretically handle threading and 3rd party frontends fine. If it's missing certain endpoints they could be added, but I'm questioning if that's really the case

@alex I don't really know the technical aspects, but threading does not work the same way in Pleroma and is very difficult to navigate in apps because replies are always listed chronologically under the original post, they don't separate into different threads. @realcaseyrollins

@alex If you give me a few minutes I can demonstrate what I mean with screenshots @realcaseyrollins

@alex Instead of a screenshot I just made a thread with 2 distinct convos, pretty good indicator of the issue. If you're familiar with 4chan you'll get the chronological format, there's no clicking to a specific reply to bring up the chain, you can hover over the "reply to" or the "# number" to see what's in response to what, and what the replies were to any particular post. (Both of those cues are missing in 3rd party apps, which is a big factor in why I don't recommend any of them to Pleroma users)

Not sure how familiar you are with image boards or Pleroma's UI but I'd just suggest comparing navigation between .com and .dev to get a feel for how they're different:

>https://gleasonator.dev/objects/0c959df6-4953-46e6-872c-8390e64c9a8d
>https://gleasonator.com/@snakeAIDS@gleasonator.dev/posts/103892352295405170
@realcaseyrollins

@shampoobottle @realcaseyrollins Ahh I think I understand now. Pleroma supports additional threading features not found in Mastodon. However, it is also completely backwards-compatible with Mastodon.

Apps like Tusky will work fine with a Pleroma server, they will just show threads in the Mastodon style instead of how Pleroma users are used to.

Pleroma also has a Mastodon UI with the same status here (gotta login again): https://gleasonator.dev/web/statuses/9tPtpkdZMvEZcmJtJY

It works as expected. The API endpoints are the same in both cases. They are:

https://gleasonator.dev/api/v1/statuses/9tPtpkdZMvEZcmJtJY
https://gleasonator.dev/api/v1/statuses/9tPtpkdZMvEZcmJtJY/context

Compare to:

https://gleasonator.com/api/v1/statuses/103892352295405170
https://gleasonator.com/api/v1/statuses/103892352295405170/context

They are the same, except the Pleroma one has an extra "pleroma" tree with additional data.

This shouldn't be a setback to Soapbox at all. If anything it adds more data rather than taking anything away.

@alex Ah, okay, that's interesting. The alternative frontends I've seen aside from MastoFE have used the default threading option so I just assumed that's how it was locked in. @realcaseyrollins

@shampoobottle @realcaseyrollins If it's an issue I can always edit the endpoint or transform the output within the frontend. Ultimately I want Facebook-style threading. This will definitely be an undertaking with a big learning curve, but it will be less difficult than writing an entire new backend from the ground up as I was planning to do a few days ago.