interoperability is the problem with this. what “integration with the fediverse” means practically for novel forms of software is “handling a trillion really annoying edge cases that Mastodon created for every other thing that isn’t Mastodon.” Lemmy, for example, handles interoperation with Mastodon incredibly poorly (and vice versa). you can do it, but for meaningful interaction it’s not very good. and forums have their own sets of edge cases that would probably make, say, forum-to-Lemmy interoperation a giant mess.
I think they’re similar enough where it could work, and thinking about it from mastodon too it’s essentially just a long trail of messages. It wouldn’t be a plugin system (I’m real sick of business people telling me to just ‘plug in’ my code), but I don’t think it’s impossible
the issue isn’t really with federating messages per se (that’s actually quite easy afaik, at least in federation terms), it’s with how to display them and everything associated with them. my understanding–based off of the fact that i’m working on a project where we’re having to fight how ActivityPub works, and how to display things is a big problem–is that ActivityPub is structured in a way you can be fast and loose with the stuff you’re federating, and it’s not a super big deal necessarily. but how it displays is a big deal, and that’s a total mess. and a lot of that mess begins with how Mastodon does stuff and the need to accommodate its choices (which i think are mostly bad for anything that isn’t microblogging, so non-microblog platforms have to design around it). it’s then amplified by differences in front-ends and clients, none of which can agree exactly on how to display or handle things, and some of which can’t/don’t display certain things at all and create differing user experiences as a result.
how Mastodon handles content warnings, for instance, is a big problem. functionally it’s just a details tag and i think in ActivityPub it’s literally just a “summary” field. but the field is–in addition to being used as a details tag, a readmore, and a summary field–primarily used as the load bearing content warning functionality on Mastodon. so everything has to kind of assume the field will be used the way Mastodon uses it, which is… an issue, to say the least. obviously, not everything can handle that (or wants to handle that) the same way by design, so you get a bunch of differing ways to display the field that might not even contextually make sense for what’s in it.
that’s what the issue is with translating from Mastodon-to-Lemmy and vice versa, and likewise would probably be the difficulty with translating stuff from forum-to-Lemmy even in a best-case scenario. i’m not even sure what the best way to handle our conversation would be, for example, since forums are often chronological/basically never indent replies/exchanges, but Reddit-alikes like Lemmy allow for different ways of sorting thread replies and do indent exchanges.
interoperability is the problem with this. what “integration with the fediverse” means practically for novel forms of software is “handling a trillion really annoying edge cases that Mastodon created for every other thing that isn’t Mastodon.” Lemmy, for example, handles interoperation with Mastodon incredibly poorly (and vice versa). you can do it, but for meaningful interaction it’s not very good. and forums have their own sets of edge cases that would probably make, say, forum-to-Lemmy interoperation a giant mess.
I think they’re similar enough where it could work, and thinking about it from mastodon too it’s essentially just a long trail of messages. It wouldn’t be a plugin system (I’m real sick of business people telling me to just ‘plug in’ my code), but I don’t think it’s impossible
the issue isn’t really with federating messages per se (that’s actually quite easy afaik, at least in federation terms), it’s with how to display them and everything associated with them. my understanding–based off of the fact that i’m working on a project where we’re having to fight how ActivityPub works, and how to display things is a big problem–is that ActivityPub is structured in a way you can be fast and loose with the stuff you’re federating, and it’s not a super big deal necessarily. but how it displays is a big deal, and that’s a total mess. and a lot of that mess begins with how Mastodon does stuff and the need to accommodate its choices (which i think are mostly bad for anything that isn’t microblogging, so non-microblog platforms have to design around it). it’s then amplified by differences in front-ends and clients, none of which can agree exactly on how to display or handle things, and some of which can’t/don’t display certain things at all and create differing user experiences as a result.
how Mastodon handles content warnings, for instance, is a big problem. functionally it’s just a
detailstag and i think in ActivityPub it’s literally just a “summary” field. but the field is–in addition to being used as adetailstag, a readmore, and a summary field–primarily used as the load bearing content warning functionality on Mastodon. so everything has to kind of assume the field will be used the way Mastodon uses it, which is… an issue, to say the least. obviously, not everything can handle that (or wants to handle that) the same way by design, so you get a bunch of differing ways to display the field that might not even contextually make sense for what’s in it.that’s what the issue is with translating from Mastodon-to-Lemmy and vice versa, and likewise would probably be the difficulty with translating stuff from forum-to-Lemmy even in a best-case scenario. i’m not even sure what the best way to handle our conversation would be, for example, since forums are often chronological/basically never indent replies/exchanges, but Reddit-alikes like Lemmy allow for different ways of sorting thread replies and do indent exchanges.