im working on a decentralized messaging app and generally up until recently i thought in such a system, if a peer is offline, you cant send a message… it wouldnt be “decentralized” if there was some central queue of messages.
it took embarassingly long, but then it hit me… git… just regular git is a decentralized database.
in my setup i need the ability for others to be abe to read and only i should be able to write to it. that functionality is out-the-box in git.
git is also pretty standardized so there are many providers if users want to move away from Github.
the storage requirements for my project are fairly small. typically small text messages. the data itself thats publicly readable would be encrypted.
GitHub has a maximum of something like 10GB of storage available. That being said, I think your described requirements don’t actually match git. If you’re just publishing messages publicly (even if encrypted) then you can do the same thing with a simple http server.
I think it’s a really poorly thought out idea.
in my project there is a focus on client-side storage. i hope it doesnt ever get to 10GB. as messages are published/read, the git DB is cleared as appropriate. i dont need the git history so i’ll do what is needed to reduce the data consumed. i dont expect it to get to that 10GB capacity, that isnt its purpose and thats a bridge i dont exprect to cross any time soon.
your absolute right about there being alternative ways to do this. i specifically want some thing a user can manage. my app right now doesnt have offline-capabilities and this is an approach to introducing that capability. using a http server would be centralizing an otherwise decentralised architecture.
i have given it some thought and i think this is the only way it makes sense for me to introduce offline messaging without centralizing.
the project is pretty complicated and its difficult to describe how it would work without an exampler so id like to share the initial idea here before i try things out to demo.
Git is designed as a permanent, historical record of text documents. You don’t “clear” it out by deleting stuff, committing, and pushing. That stuff still exists, even if you change commit history it’s going to stick around in the reflog for a long time.