IPFS doesn't require git, and it's licensed under MIT. IPFS doesn't have any concept of file or directory versioning; are you mixing it up with Dat?
I'm not sure what you mean by "isn't rooted in HTML/http concepts". IPFS lets you share files and fetch them in a content-addressed way individually or grouped in directories, like a re-imagining of BitTorrent+magnetlinks built for the browser and website use-case. IPFS is usable through web gateways with regular browsers. An IPFS gateway can either be a public gateway (like gateway.ipfs.io), or it can be set up to serve a specific IPFS url for a given domain name. I can make mydomain.com have a DNS record that says the site's content is available at a certain IPFS hash, and then I can set up A/AAAA records pointing at a server which runs the standard ipfs daemon and serves only that IPFS hash, so regular browsers can access my site normally, and people with the ipfs companion extension or future ipfs-compatible browsers will automatically fetch my site's content from the ipfs p2p cloud when they visit mydomain.com, which is useful if my server ever goes down and other people have my content pinned. Cloudflare.com actually has a service where they'll run the ipfs daemon for your domain, so you can set the DNS ipfs record and just worry about keeping your content in available ipfs (possibly with a pinning service) without needing to keep your own web servers up.
As far as I can tell, Dat doesn't support or at least doesn't emphasize this web gateway use-case. From reading about it, Dat seems to have a bunch of features like directory versioning, allowing clients to publish files within a page, and some browser WebRTC-like p2p swarm thing, which sound neat, but also require its own browser and sounds like it's making its own separate browser ecosystem. To me, IPFS feels like it's doing one thing, it's easy for me to picture how to slot it into my current understanding of the web next to existing technologies, and it's easy for me to envision a future where it's incrementally adopted (in the graceful fallback style that most web progress has followed) and maybe even becomes part of browsers.
(Though I feel IPFS still has a number of UX and reliability problems, like unpredictability in ability to fetch a resource, lack of information about fetching/pinning progress, and web gateways and the ipfs companion extension are still a bit janky. There needs to be some nice front-end for pinning sites you look at, enforcing that your pins don't take too much bandwidth or disk space, and updating your pinned content as sites update. But it seems all of these things could be solved with it still retaining roughly the same interface.)
> I'm not sure what you mean by "isn't rooted in HTML/http concepts".
Yeah, sorry, what I meant was that it has a protocol spec (eg. as an RFC or equivalent), and not just one canonical client and server impl, resp., and aligns with HTTP's concept of a network entity, URL, or even ETag, etc., because that'd be natural for my use case.
I'm not sure what you mean by "isn't rooted in HTML/http concepts". IPFS lets you share files and fetch them in a content-addressed way individually or grouped in directories, like a re-imagining of BitTorrent+magnetlinks built for the browser and website use-case. IPFS is usable through web gateways with regular browsers. An IPFS gateway can either be a public gateway (like gateway.ipfs.io), or it can be set up to serve a specific IPFS url for a given domain name. I can make mydomain.com have a DNS record that says the site's content is available at a certain IPFS hash, and then I can set up A/AAAA records pointing at a server which runs the standard ipfs daemon and serves only that IPFS hash, so regular browsers can access my site normally, and people with the ipfs companion extension or future ipfs-compatible browsers will automatically fetch my site's content from the ipfs p2p cloud when they visit mydomain.com, which is useful if my server ever goes down and other people have my content pinned. Cloudflare.com actually has a service where they'll run the ipfs daemon for your domain, so you can set the DNS ipfs record and just worry about keeping your content in available ipfs (possibly with a pinning service) without needing to keep your own web servers up.
As far as I can tell, Dat doesn't support or at least doesn't emphasize this web gateway use-case. From reading about it, Dat seems to have a bunch of features like directory versioning, allowing clients to publish files within a page, and some browser WebRTC-like p2p swarm thing, which sound neat, but also require its own browser and sounds like it's making its own separate browser ecosystem. To me, IPFS feels like it's doing one thing, it's easy for me to picture how to slot it into my current understanding of the web next to existing technologies, and it's easy for me to envision a future where it's incrementally adopted (in the graceful fallback style that most web progress has followed) and maybe even becomes part of browsers.
(Though I feel IPFS still has a number of UX and reliability problems, like unpredictability in ability to fetch a resource, lack of information about fetching/pinning progress, and web gateways and the ipfs companion extension are still a bit janky. There needs to be some nice front-end for pinning sites you look at, enforcing that your pins don't take too much bandwidth or disk space, and updating your pinned content as sites update. But it seems all of these things could be solved with it still retaining roughly the same interface.)