random-ideas

rkle Tree is a valid Merkle DAG, since a node can _optionally_ include a data payload. So a blockchain, a blocktree, and a blockdag are all also Merkle-DAGs. Merkle-DAG is a kind of unifying structure that can be used to model all of them. It's really quite clever. https://docs.ipfs.tech/concepts/merkle-dag/ This appears to have been coined in 2014: https://github.com/jbenet/random-ideas/issues/20 However the term blockchain dates back to at least 2008. A blockchain might be a Merkle-DAG but a Merkle-DAG is not a blockchain.

of the best "original ideas" in the IPFS body of work were probably first discovered decades prior. I repeatedly see people succumbing to sadness over multiple discovery. It shouldn't be sad, it should be a happy event, as it confirms our own thoughts and presents an opportunity for collaborations. :) Further thoughts here: https://gist.github.com/jbenet/8f000606f2009495c56177f6ca2c1...

cause we want something rock solid to last for decades. This means it takes us a lot longer to build high perf and high quality UX, because there's a lot more to do. More work, but it is all achievable. The rough edges will disappear as we improve the tooling. Even today, gx is amazingly simple and powerful, and already does much for dependability. It's worth mentioning other package management tooling we're working on too: * NPM + IPFS - https://github.com/diasdavid/registry-mirror and other repos. This is an effort to improve how NPM works with IPFS * pacman + ipfs - https://github.com/ipfs/notes/issues/84 - this is a super rough way to show how to add ipfs support to a package manager through FUSE. it's not the best way, but it works! * also, we <3 nix, and cool stuff coming in the future there :) We have LOTS in development and store for the package manager communities. It's a very exciting time. Please join us at https://github.com/ipfs/ipfs and #ipfs and #gx on freenode IRC. And, if anyone wants to work on "Hypermodular Programming" with us, see https://github.com/jbenet/random-ideas/issues/27 and ping me :)

e web browser. It even works in desktop apps (via Electron or NW.js) and mobile apps (via embedding the webrtc.org library). With WebRTC, we can connect all types of endpoints (desktop, web, mobile) directly and completely P2P. This is the underlying transport that all future P2P protocols should be built upon. Right now, the primary limitation of WebTorrent in the browser is that you can't just paste in any random magnet uri or .torrent file and have it work. The torrent must be seeded by a WebRTC-capable client, i.e. webtorrent-hybrid (https://github.com/feross/webtorrent-hybrid) or https://instant.io. We plan to build a desktop client (soon!) that can connect to normal BitTorrent peers, as well as WebRTC peers. These long-running peers will ensure there's lots of content available in the network that the shorter-running web peers can access. This is the vision: All torrent clients (desktop, web, mobile) talking directly to each other. If you're interested in learning more about the idea of "WebRTC everywhere", here are some links: https://github.com/webrtcftw/goals/issues/1 https://github.com/jbenet/random-ideas/issues/13

ml#commentary) describing what it does, and the type signature (yes, static typing). As you write, [your editor suggests](http://npmsearch.com/?q=factorial) lists of functions [published to the web](npmjs.org) (public or private) that match what you're typing. One appears promising, you inspect it. The editor loads the code. If it is exactly what you were going to write. You select it, and you're done. If no result fits what you want, you continue to write the function implementation. You decompose the problem as much as possible, each time attempting to reuse existing functions. When done, you save it. The editor/compiler/system parses the text, analyzes + compresses the resulting ASG to try to find "the one way" to write the function. This representation is then content addressed, and a module consisting of the compresses representation, the source, and function metadata (doc string, author, version, etc) is published to the [(permanent) web](http://ipfs.io/), for everyone else to use. ### Important Ideas - exporting a symbol (functions, classes, constants, ...) is the unit of modularity (node) - system centered around writing _functions_ and writing them once (node) - stress interfaces, decomposition, abstraction, types (haskell) - use doc string + function signatures to suggest already published implementations (node, Go) - content address functions based on compressed representations - track version history of functions + dependents (in case there are bug fixes, etc). (node) - if a function has a bug, can crawl the code importing it and notify dependents of bugfix. (node, Go) - use static analysis to infer version numbers: `<interface>.<implementation>` (semver inspired) - when importing, you always bind to a version, but can choose to bind to `<interface>/<implementation>` or just `<interface>` - e.g. `factorial = import QmZGhvJiYdp9Q/QmZGhvJiYdp9Q` (though editors can soften the ugly hashes) (node + ipfs) - all modules (functions) are written and published to the (permanent) web (public or private) - when importing a function, you import using its content address, and bind it to an explicit local name (`foo = import <function path>` type of thing) - the registry of all functions is mounted locally and accessible in the filesystem (ipfs style) - _hyper modular_ means both to "very modular" and "modules are linked and on the web" Note: this system is not about the language, it is about the machinery and process around producing, publishing, finding, reusing, running, testing, maintaining, auditing, bugfixing, republishing, and understanding code. (It's more about _the process of programming_, than _expressing programs_). This means that the system only expresses constraints on language properties, and might work with modified versions of existing languages.