-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Distribution of maps by mappers and modders #21
Comments
I have some doubts about this. Can someone that didn't send they key see files at least? And huh, what happens if someone just deletes a file? Or corrupts one by accident? This sounds like it also makes it easier to loose work everywhere. |
Whats the benefit compared to a central repository and packet manager? |
Of course. We're talking about public keys here. Only needed to send, not to read.
Syncthing does claim to have history feature. But syncthing is just an example for implementation.
Lower official maintenance. Central stuff requires officially appointed people to maintain it, while my proposal allows informal spreading, outside of official responsibility. |
If it is decentralized and without any direct official control can't this already be used? How would the practical use be?
What happens with harmful and illegal content if there is no moderation? |
As I understand it, this boils down to a question for a central decentralized map repository.
|
For now, when someone creates a map, port a map from another game (including tremulous), repack a map from tremulous (port != repack, repack is just about moving files around and generating navmeshes), modifies a map, etc, there is no way to easily share the result and keep it up to date.
What I would suggest is a mechanism like a syncthing network.
Why syncthing? Because it's based on both parts exchanging their keys. Unlike git, it's bi-directionnal. Unlike git, it does not shares or stores history (useful for people with small storage space!).
There's likely many other solutions, but to find one, the question must be asked.
I understand it's far from perfect, though, and there's a lot of policy behind. But I think this tool, which wants both public keys of emitter and receiver to do a data exchange, could be a good starting base.
The text was updated successfully, but these errors were encountered: