chat history imports #192

core441 commented 2026年04月26日 09:57:40 +02:00

Add a command to retroactively bridge all previously sent content in a channel, effectively re-constructing a server's history on the source platform. This would make migrating to other platforms a breeze for users, further advancing the proliferation of privacy-respecting, user-respecting, and (in some cases) federated social platforms.

Add a command to retroactively bridge all previously sent content in a channel, effectively re-constructing a server's history on the source platform. This would make migrating to other platforms a breeze for users, further advancing the proliferation of privacy-respecting, user-respecting, and (in some cases) federated social platforms.

Andre601 commented 2026年06月05日 18:33:28 +02:00

Giving my feedback on this, I would say this command should A) have a set limit of how far back it can go and B) make it a admin (bot owner) only command.

Reasons for A):
This would obviously create a ton of new data to store in the bots database, not to mention create a possibly huge number of requests on the other platform(s), which can cause delays (if rate limits are properly handled) or in worst case even (temporary) bans from the API.
So limiting it to a certain amount - either based on a timeframe like "last 2 weeks" or a message count itself - could avoid these problems.

Reasons for B):
For self-hosted bots may this not be a major issue, but for publicly hosted ones like Bolt could this be a problematic situation where someone executes the command and causes the issues pointed out above. slowing down the bot. or even getting it blocked (temporarely).
So some safety mechanic should be made here.

Giving my feedback on this, I would say this command should A) have a set limit of how far back it can go and B) make it a admin (bot owner) only command. Reasons for A): This would obviously create a ton of new data to store in the bots database, not to mention create a possibly huge number of requests on the other platform(s), which can cause delays (if rate limits are properly handled) or in worst case even (temporary) bans from the API. So limiting it to a certain amount - either based on a timeframe like "last 2 weeks" or a message count itself - could avoid these problems. Reasons for B): For self-hosted bots may this not be a major issue, but for publicly hosted ones like Bolt could this be a problematic situation where someone executes the command and causes the issues pointed out above. slowing down the bot. or even getting it blocked (temporarely). So some safety mechanic should be made here.