Also why the license is AGPLv3, now.

puts bizdev hat back on

Yeeeesss @linc@phpc.social, please add Discourse as a migration source

Each forum company treats their migration scripts as proprietary product, because it literally gives end users the means to migrate away to competitors. It also means they're usually janky as hell and each company has to come up with their own bespoke migration logic.

My end goal with NodeBB wasn't to destroy my competition (although that'd be a nice side effect), it was to improve the forum UX and encourage adoption of forums as a whole. Up until the 2010s, forums were unequivocally dying as a form of communication. It was an existential rationale!

So Lincoln's work only helps further that goal.

We've been trying to find paying clients to help fund Linc's work (to build out the NodeBB target), but those customers are very far and few between. That's why there hasn't been movement until @nlnet@social.nlnet.nl came in with the Open Social Fund.

cc @benpate@mastodon.social

I think interconnectedness is a double-edge sword, so my own work in the community space right now is focused on private community organizing with only very selective feed-based connections.

... though I still wish all of this were easier to interconnect.

Nitro Porter is trying to solve *collective* data sovereignty — as a group, what do we want to do with our shared data — which doesn't make sense outside *private* context.

I am not sure Mastodon translates.

I'll try to get up to speed on what you've been doing, and then see how it might fit with my own work. Would you say this could work for "non-forum" software, too, such as a regular Mastodon server?

Backwards compatibility requirements make big changes like that very iterative but I finally got there.

If someone wants to add support in the meantime, I'm always happy to chat and answer questions.

My biggest wish for any project is to build in their own tools for recalculating derived data — post counts, point totals, last post in a topic, etc.

Most apps assume you've never used any other platform or that their calculated data could be wrong. It's a huge time sink to "fix" data handling for them in an export.

To add support to Nitro Porter directly, there's a guide in the docs: https://nitroporter.org/develop.html

Data Portability is certainly one of the keys to making a healthy online ecosystem.

What would a project need to do in order to support Nitro Porter?

@linc @nlnet @nodebb

I could see a static HTML export one day, but it's a bigger lift because there's no framework for presentation logic today. Then, of course, folks would have feelings about theming.

If I did, I'd perhaps pair it with a scraping feature so it's not as irreversible & "orphaned" as a feature.

Interesting idea!

What would be a very nice feature is supporting migration to an archive format that can be hosted on a static site, after a community winds down and ceases to exist.

Typically I add platforms as a Source first because it's easier, but I was trying to prioritize some high-visibility items I'd be unlikely to do this year otherwise and are harder to sponsor as 1-offs due to scope. Source = $, Target = $$$

If I modify the scope later because an existing goal isn't panning out, that's high on my list to get in there. It's inevitable, it's just timing.