I think how operators obtain their data, and the TOS contract between them and any platform are their own concern. Fluxer isn't pushing anyone toward breaking any platform's TOS since the proposed API is source-agnostic, which is a much softer implementation than some of the precedents above. I see data import as a fundamental feature any chat platform should have to give hosters more control over their software.
Migration fidelity
My feature targets communities that value high migration fidelity. Say a server operator discovers Fluxer and is interested in the prospect of moving their community and the memories they built over the years. But, upon researching further, they learn that the only way to migrate data is lossy per-user dumps that likely leave historical user interactions as one-sided conversations. They are left with the decision to either start a fresh Fluxer instance and forget about history or look for alternatives that do allow data import. I personally don't think many admins/users will want to bother with the manual labor involved in moving a community on a per-user basis.
By lossy I mean (in the case of Discord user data exports as an example):
No reactions
Attachments are exported as expiring links (~24h), which are likely already lost by the time a user presents their data.
Missing pins, embeds, rich content and other metadata
Side-note: Discord user data exports contain IPs and payment information, so we don't want to encourage people uploading that.
Other data that is not covered by a per-user migration:
Data from departed users
Bot accounts and messages
Miscellaneous messages like webhooks and "user X joined".
Federation
I think these two features can work alongside each other. My import feature allows external data to flow into the Fluxer ecosystem in a general way. Once a user claims this data, they have the ability to do whatever they want with it. They can request their high-fidelity data to be moved to any federated instance they like or they can delete it if they so choose. In any case (whether for user uploaded data approved by an admin or for external admin tooling support), we need API endpoints to write these objects into an instance. I think my proposal addresses that.
Thread
Comment waiting for review
Comment by @ilianbronchart
TOS
There's precedent for my proposed feature (I actually didn't know the extent, these are useful references to have):- Zulip has importers for Mattermost, Slack, Rocket.Chat: See Here. It even specifically mentions importing data from a Rocket.Chat database dump.
- Mattermost has support for Bulk loading data
- Rocket.Chat has UI for Slack data imports and a CSV importer
I think how operators obtain their data, and the TOS contract between them and any platform are their own concern. Fluxer isn't pushing anyone toward breaking any platform's TOS since the proposed API is source-agnostic, which is a much softer implementation than some of the precedents above. I see data import as a fundamental feature any chat platform should have to give hosters more control over their software.Migration fidelity
My feature targets communities that value high migration fidelity. Say a server operator discovers Fluxer and is interested in the prospect of moving their community and the memories they built over the years. But, upon researching further, they learn that the only way to migrate data is lossy per-user dumps that likely leave historical user interactions as one-sided conversations. They are left with the decision to either start a fresh Fluxer instance and forget about history or look for alternatives that do allow data import. I personally don't think many admins/users will want to bother with the manual labor involved in moving a community on a per-user basis. By lossy I mean (in the case of Discord user data exports as an example):- No reactions
- Attachments are exported as expiring links (~24h), which are likely already lost by the time a user presents their data.
- Missing pins, embeds, rich content and other metadata
Side-note: Discord user data exports contain IPs and payment information, so we don't want to encourage people uploading that. Other data that is not covered by a per-user migration:Federation
I think these two features can work alongside each other. My import feature allows external data to flow into the Fluxer ecosystem in a general way. Once a user claims this data, they have the ability to do whatever they want with it. They can request their high-fidelity data to be moved to any federated instance they like or they can delete it if they so choose. In any case (whether for user uploaded data approved by an admin or for external admin tooling support), we need API endpoints to write these objects into an instance. I think my proposal addresses that.