Oddbean new post about | logout
 Both bad ideas.  Git is fine. 
 No it is not fine. Git is very bad for key value store sync. If you want to sync all files with specific prefix or within a specific range, you are screwed. 

That doesn't matter when you have 100 rarely changing files, but it does matter when you have 10s of thousands and the list changes very frequently  
 It was Steve Jobs that said "increase the simplicity by 10%, and double the adoption".

I'm sure a very complex solution will work (bear in mind solutions are never complex in the mind of the developer that implements it), but the adoption suffers exponentially.

Git is well adopted and that is quite important. 
 as you can see, it is going to be optional API, as evident by not already existing.

If you don't want to help lower the cost of crawling Homeservers, you won't need it. But the developers working on our Indexer are already feeling the pain of not having a way to cheaply sync with the homeserver. This is going to get way worse after users are able to migrate between servers, suddenly indexers will find themselves downloading entire user's data twice if they don't have a cheap way to recognise that they already did that work before.

wiring git in the homeserver not only not sufficient for our needs it might be more complex too. 
 I think you might be slightly dismissing the complexity here, we've been working on this for 10 years at MIT and with solid.  These are hard problems with many edge cases.  But I dont underestimate  your ability to solve hard problems.  If you get it working well, will use!