Is your feature request related to a problem? Please describe.
Even if the ZeroNet site is distributed across multiple users, its owner still has full site access. This means that he can delete/modify the site so others won't be able to use it. Or even worse, put some changes that could be malicious but very hard to spot.
Describe the solution you'd like
ZeroNet should have a plugin for tracking site changes in Git. That plugin should:
.git the directory from the remote site or store it on different location outside site directory (to prevent site owner from overwriting it)Then, users could just view site changes directly in UI or alternatively view them in a dedicated Git program if they are more advanced.
Describe alternatives you've considered
A simple solution is to manually create a repository and manually commit all changes. However, this has a downside because the site owner will probably be able to overwrite local .git directory and it is also not so convenient to manually commit every change.
Additional context
This is based on ZeroTalk topic.
It would be a great addition, idea for configuration options per site:
* Create new commit every: minute, hour, day (new commit for every change probably would be inefficient)
Are you kidding me ?
a downside because the site owner will probably be able to overwrite local
.gitdirectory
Do you think malicious user would keep git repo as you wish ?
Are you kidding me ?
Adding 1000 files as separate commits: 7 min, 29 MB .git
Adding 1000 files as 10 commits: 6 sec, 3.6 MB .git
I see no real reason to commit every change, but sure, that should be an option too.
@HelloZeroNet That's not the point, but content-addressing.
They should commit once or more each time they publish, obviously
The proposal is for a local git repository, other users won't be able to reach it, so not sure what you mean by content addressing
As @filips123 said:
That should give me an easy way to check changes when a zite owner updates.
I think it is a low probability that some "agency" would push out malware to a zite. They like to keep their exploits secret and sending one to every zite user in an update would effectively "blow" that exploit. Never know though...
It's for tracking changes and prevent malware
Posting an issue for a local repo makes no sense
Yes, the commit interval should also depend on the file type/location:
It's for tracking changes and prevent malware
It is for local tracking of changes. This means that user would have local Git repository to store changes, and this plugin would automatically commit/track changes instead of user.
Few examples why this could be useful. Owner of some popular site can delete it. If changes are tracked (even if locally), other user can restore and publish it. Or site can get malicious update. With tracking, user can spot this and identify when did the change happened.
why this could be useful.
No, site owners can directly modify the git repo instead of commiting
Yes, so
Ignore .git the directory from the remote site or store it on different location outside site directory (to prevent site owner from overwriting it)
Even better to store .git in different directory, so it could not be written by the site owner.
maybe auto sharable to site peers(so that everyone keeps git logs and shares to peers that ask for it)
redundancy and you dont need to count on yourself(sites are signed by owner so it's not possible to fake)
but begin realistic maybe this is just over engineering
Most helpful comment
It is for local tracking of changes. This means that user would have local Git repository to store changes, and this plugin would automatically commit/track changes instead of user.
Few examples why this could be useful. Owner of some popular site can delete it. If changes are tracked (even if locally), other user can restore and publish it. Or site can get malicious update. With tracking, user can spot this and identify when did the change happened.