According to Solid chat today ActivityPub has been getting a lot of adoption. This might make it interesting for SAFE projects like Decorum or for general compatibility between the Standard Web and SAFEnetwork, although I’m not sure such a Federated based approach maps well to SAFE. Having said that, yesterday I was thinking that the ssb-git (which is federated, ie git over secure scuttlebutt) could map really nicely to SAFEnetwork for a SAFE-Git, so these approaches are worth looking into, or a topic to discuss with Tim at some point. cc @Viv@krishna
Both @nice and I have been playing with ssb-git and Scuttlebutt apps with some success:
i kinda do dislike ssb. i think it has the same issues as blockchains in regard to scalability. It’s ok if you have your own pub and thus only see a slice of the “world” but if you try to download the whole “world” then you’re lost.
I have a plan for how, but not the time to do this for now (want to get virtual drive done first). So if anyone wants to get this started I can suggest how to build it and help things along thanks to noffle, one of the Scuttlebutt guys, see:
SAFE git remote
We can build a git remote-helper for git with Nodejs using the CLI Boilerplate I made. This will enable people to use SAFEnetwork as a git remote with push, pull and fetch etc.
It would use a similar method to git-ssb to publish changes to a feed which others can consume (kind of pub/sub I think).
If the first part is similar enough to git-ssb it should be a simple matter to modify git-ssb-web to make a web front end similar to github.
Anyone fancy a go at this? I don’t mind you taking it over, me helping out, me leading, or me doing it in my own, but can’get it done quickly by myself. In fact it will be verrrry slow
I think Pijul is a better contender for decentralized networks than git.
Git takes a whole snapshot of workspace for each commit
then it tries to find matching objects at the storage level and stores just the diffs to save space
thus creates one compressed file which changes each time it’s recreated (git gc or autogc), resulting in a completely new file containing all the repository data, which can’t be efficiently stored (deduplication) on a content-addressable-network (immutable data)
Pijul stores a patch for each commit
then stores these patches as files at the storage level
thus one additional commit is just one additional file => old patch files don’t change thus they can be efficiently stored on a content-addressable-network
tldr: git compresses all data to one file at the storage level, resulting in non-deduplicatable data. pijul works with compressed data (patches) at all levels, thus all patches can be stored as self-contained units allowing deduplication.
I think SAFE itself has a very efficient mechanism: make a snapshot of the data maps, save to Immutable Data and keep a pointer to that in a list along with tags etc. Not thought through, but illustrates the idea.
With that as the backend I think you can write a ‘git bridge’, to use git as the front end. Possibly there are also similar ways to use other Version Control Systems as the front end, with a very efficient SAFE VCS backend.
All just ideas for now though! Busy elsewhere
Thanks for this though, it triggered the above thought!
UPDATE: I looked into Pijul a bit and it is interesting, although still alpha and obviously not well known or adopted. One to watch. Here are two articles I found helpful:
Pijul is also implemented in the Safe Network’s native language, Rust. I had not heard of this VCS before it looks very interesting and appears to be much better suited to the Safe Network way of doing things.
pijul’s effortless merging and reordering might really lead to new and productive workflows. Are you old enough to remember when git was new and most people were still on SVN (or even CVS)? Lots of people were (quite reasonably) skeptical. “Who cares about easy branching? It’s better to merge changes immediately anyway.” Or, “who cares about distributed repositories? We have a central server, so we may as well use it.” Those arguments sound silly now that we’re all used to DVCSes and the workflow improvements that they bring, but it took time and experimentation to develop those workflows, and the gains weren’t always obvious beforehand. Could the same progression happen with pijul?
Grow into a new modern Safe Network, and a new VCS, the projects could complement one another.
After reading some about Pijul, I am quite curious to try it out.
I manage a lot of Git merging from our software projects, and Pijul has some really nice characteristics that would have made things much easier. It seems like a more elegant solution.
Isn’t SAFE cloned and backed up on multiple repositories, not just github? If not it should be. This move by Microsoft just proves the over dependence on centralization, even on an opensource brand like Github, breeds in weakness.
At minimum, before we have a truely safe based repository system, I would like to be able to check the checksums from outside github when Maidsafe releases binaries and distribute these on Github. The checksums should be computed locally at Ayr, and could be published here on the forum, for instance. I have absolutely no trust in Microsoft, and would love to be able to make sure they don’t stuff nasty blobs in the files.
Yet another example of the importance of SafeNet / Parsec. With SafeNet / Parsec, the idea of buying and selling sites will be in the past. Seeing as SafeNet sites will be stored / hosted within SafeNet itself by way of the vault system: once services are created and installed into SafeNet, they are there for as long as there are humans who let the Internet itself continue to exist.
With SafeNet people can of course branch off their own variations of things, but they can’t destroy the original. Man corporations are going to have a love-hate relationship with SafeNet. lol
I just noticed your late edit update by accident @happybeing - quoting in case others following this thread miss it as well.
Referring to the twitter thread - As the Safe Network is itself is “next gen” and at least a year or two off, it could be beneficial to adopt Pijul from the get go for Safe Network usage for all the advantages as outlined by @urrtagabove/rebasing cannot take advantage of de-duplication. The Safe Network and Pijul could become synonymous, helping each project grow together. If the combination provides clear advantages for developers then it would cause positive feedback loop for both projects.
Git already has some very well established convenient (mostly centralised) options so we would be fighting the developer mind share war on others extremely well established turf. Expect Microsoft to begin the great “GitHub integration into everything” effort now with all the money and marketing power at their disposal. By adopting Pijul for the Safe Network it would be possible to change and up the game on the Safe Network’s terms blasting inroads into the developer mind share with a better DVCS on all counts running in the best and most secure decentralised network ever built (assuming Pijul is upto the task of course I can’t wait to get an opportunity to try it out).
Adopting new techniques is always going to be painful and resisted by some - I remember having to be dragged off SVN back in the day, but in this case it would be easier at the start of the Safe Network launch rather than hammering git sort-of into Safe Network then later realising Pijul is the way forward for a decentralised network and having to then deal with all the fragmentation that brings with it.
yeah IPFS is using GX for a while. I really dislike that you need to put the hash of the package in your code (also a reason why i hate go-lang, bc you need to put the url to dependencies inside each file which is using that dependency and change all files on updates, and also that there is no fukking versioning of packages in go, but at least gx is addressing this).
I would encourage you to actually use “Safe Network” instead of “SafeNet” since the latter is another project unto itself. Regulars here will use “Safe Network” and know what you mean, but please try to make it a clear distinction in your future wording.