4 ms·

You're dead on. It's staggering in its power -- permissionless composability, even if most of the data is not on-chain, and the programs are very limited in si

You're dead on. It's staggering in its power -- permissionless composability, even if most of the data is not on-chain, and the programs are very limited in size/complexity due to the expense of running them. Now, imagine a system where all of the data is also on-chain, and the programs you can compose are full-complexity applications... All while maintaining every independent program's data invariant in a completely decentralized manner, with transaction rates that grow linearly with the DHT size. Such a system is now in public beta. It could be world-changing (at least for programmers).

daveguy 4y ago
How is permissionless composability different from the MIT license? I'm confused what you're composing now that you couldn't before and the benefit of that permissionless composability. Ecosystems of programming libraries and compostable abstractions don't require a blockchain as far as I can tell.
- pjkundert 4y ago
  It's like the MIT license, plus AWS with an unlimited account and auto-scaling. In the case of self-hosted Apps (ie. where you need to "install" something on your phone or computer), each peer provides their own compute/storage/networking to host their own usage of the App, plus a small fragment of everyone else's usage (proportional to a few average user's worth). So, the cost to each user is a small constant C times the average user's utilization. And the benefit is that the application persists, in its entirety, as long as any number of users >= 1 continue to use the App.
  - hestefisk 4y ago
    It’s not really an unlimited account. Execution on eth is expensive…
    - pclmulqdq 4y ago
      It's like AWS serverless compute with inefficiency built-in as a feature and a jacked-up billing rate.
      - daveguy 4y ago
        This concept is very interesting. Is there an existing framework that implements this? It would seem there would need to be some baseline tools for development on such a system. I feel like the tools available for this purpose would need to be more powerful than existing IDE systems in order for it to be adopted on a wide scale. Is it possible to design such a system without a blockchain?
    - pjkundert 4y ago
      Yes, in the case of Ethereum "DeFi", the end user is expected to pay the (significant) cost of executing functionality. For next-gen "DeFi" systems like Holochain -- the incremental cost of executing functionality is vanishingly small, and can be distributed across a DHT substrate hosted by all users of the App. A self hosted Holochain "DeFi" app costs a small constant factor C times the average agent's memory / network / storage cost, to each client. In other words, you gain the benefit of the "DeFi" version of App for yourself, by investing a small C x your own cost to run the App for yourself, alone.
- scyclow 4y ago
  The big difference is that a smart contract is a running, stateful, immutable piece of software. Alternatively, I can run software with an MIT license by myself, but I can always modify the data or API without any approval of the users.
  - daveguy 4y ago
    This is interesting. Essentially a reference piece of software where anyone on the network can run the exact same bits (assuming they have compatible hardware). But also the ability to extend or compose where the new system will also have a reference identity. This may have use in defining standards. You could have a standards authority without any actual standards body. Free but standard.
  - meltedcapacitor 4y ago
    In practice almost every vaguely live protocol has god mode where some "Sam" can upgrade the contract to whatever they want, because bug risk in immutable contracts is too high (VCs who fund the projects don't want to be sued for bugs). So this becomes functionally equivalent to a SQL server just slow and taking 100x the server capacity.
NotYourLawyer 4y ago
What’s the use case for this? I’m not seeing it.
- pjkundert 4y ago
  You see no benefit in Apps that cannot be "disappeared" by anyone (even the person who deployed it), and which scales without bound and can be composed (re-skinned or extended) without restriction? Or, forked and restricted to your own cryptographically identified and secured set of users?
  - ctvo 4y ago
    Can you answer the question with use cases and examples instead of this rhetorical question? It doesn't help your credibility when you can't list off 10-20 use cases and examples for your groundbreaking technology without contorting yourself.
    - pjkundert 4y ago
      I'm sorry; but isn't this sort of like demanding an answer to the question "I can't see a use for the motorcar; horses work just fine"?
      - Tesl 4y ago
        no
      - jrek 4y ago
        Not at all, in the sense that if you were asked THAT question, you’d easily be able to come up with a convincing answer.
  - pclmulqdq 4y ago
    What is the value proposition of "can't be disappeared by anyone" exactly? Reversibility and deletability are actually features of most systems. Scales without bound is cool, but generally lacks use and is expensive. I would rather scale to my actual usage bounds rather than paying for infinite scalability. Composed without restriction is cool, but I got that with the MIT and BSD licenses. Forked and restricted has already been possible using traditional open-source computer infrastructure.
rapind 4y ago
> It could be world-changing (at least for programmers). If you don’t mind, could you give an example for a programmer who isn’t building finance or crypto related applications? I think that would help me understand what we’re talking about.
- pjkundert 4y ago
  https://twitter.com/pjkundert/status/1590009435619217413 https://twitter.com/pjkundert/status/1590009435619217413 The clutter.social App is a decentralized Twitter-like app implemented on Holochain. This one is hosted on https://holo.host https://holo.host (only in public Beta, so it doesn't scale automatically), but illustrates a full-complexity app that is deployed. You can compose this (eg. re-skin it, or build it into another app as a commenting back-end), without having to copy the implementation or host the data. You can also "clone" such an app (with or without any functional changes) and host that fork yourself (eg. on a company’s or family's computers), and nobody can stop you.
  - dnissley 4y ago
    Who pays the hosting bills for the app? If whoever is responsible fails to pay the hosting bills, presumably the app will cease to function and perhaps even disappear? When I fork it, do I maintain my ability to communicate with users who live on the "source" app?
    - pjkundert 4y ago
      The App's current owner(s) pay, of course. For traditional "installed" Apps, this could easily be the current (and new) end-users of the App. For a purely hosted app (eg. an App that serves web clients), hosting must be arranged. If the App has no revenue model to pay for hosting, perhaps don't use it (embed it) within your app? That would be a risk. If you "fork" it, then you're responsible to host it -- if it isn't hosted by each client App installation already. The "forked" version of the App hosts its own DHT, so its data is completely distinct from the original. So, yes: there are decisions to be made, but they revolve around long-term viability of the encapsulated/forked App -- not the fundamental possibility of doing so.

daveguy 4y ago

How is permissionless composability different from the MIT license? I'm confused what you're composing now that you couldn't before and the benefit of that permissionless composability. Ecosystems of programming libraries and compostable abstractions don't require a blockchain as far as I can tell.

pjkundert 4y ago
It's like the MIT license, plus AWS with an unlimited account and auto-scaling. In the case of self-hosted Apps (ie. where you need to "install" something on your phone or computer), each peer provides their own compute/storage/networking to host their own usage of the App, plus a small fragment of everyone else's usage (proportional to a few average user's worth). So, the cost to each user is a small constant C times the average user's utilization. And the benefit is that the application persists, in its entirety, as long as any number of users >= 1 continue to use the App.
- hestefisk 4y ago
  It’s not really an unlimited account. Execution on eth is expensive…
  - pclmulqdq 4y ago
    It's like AWS serverless compute with inefficiency built-in as a feature and a jacked-up billing rate.
    - daveguy 4y ago
      This concept is very interesting. Is there an existing framework that implements this? It would seem there would need to be some baseline tools for development on such a system. I feel like the tools available for this purpose would need to be more powerful than existing IDE systems in order for it to be adopted on a wide scale. Is it possible to design such a system without a blockchain?
  - pjkundert 4y ago
    Yes, in the case of Ethereum "DeFi", the end user is expected to pay the (significant) cost of executing functionality. For next-gen "DeFi" systems like Holochain -- the incremental cost of executing functionality is vanishingly small, and can be distributed across a DHT substrate hosted by all users of the App. A self hosted Holochain "DeFi" app costs a small constant factor C times the average agent's memory / network / storage cost, to each client. In other words, you gain the benefit of the "DeFi" version of App for yourself, by investing a small C x your own cost to run the App for yourself, alone.
scyclow 4y ago
The big difference is that a smart contract is a running, stateful, immutable piece of software. Alternatively, I can run software with an MIT license by myself, but I can always modify the data or API without any approval of the users.
- daveguy 4y ago
  This is interesting. Essentially a reference piece of software where anyone on the network can run the exact same bits (assuming they have compatible hardware). But also the ability to extend or compose where the new system will also have a reference identity. This may have use in defining standards. You could have a standards authority without any actual standards body. Free but standard.
- meltedcapacitor 4y ago
  In practice almost every vaguely live protocol has god mode where some "Sam" can upgrade the contract to whatever they want, because bug risk in immutable contracts is too high (VCs who fund the projects don't want to be sued for bugs). So this becomes functionally equivalent to a SQL server just slow and taking 100x the server capacity.

NotYourLawyer 4y ago

What’s the use case for this? I’m not seeing it.

pjkundert 4y ago
You see no benefit in Apps that cannot be "disappeared" by anyone (even the person who deployed it), and which scales without bound and can be composed (re-skinned or extended) without restriction? Or, forked and restricted to your own cryptographically identified and secured set of users?
- ctvo 4y ago
  Can you answer the question with use cases and examples instead of this rhetorical question? It doesn't help your credibility when you can't list off 10-20 use cases and examples for your groundbreaking technology without contorting yourself.
  - pjkundert 4y ago
    I'm sorry; but isn't this sort of like demanding an answer to the question "I can't see a use for the motorcar; horses work just fine"?
    - Tesl 4y ago
      no
    - jrek 4y ago
      Not at all, in the sense that if you were asked THAT question, you’d easily be able to come up with a convincing answer.
- pclmulqdq 4y ago
  What is the value proposition of "can't be disappeared by anyone" exactly? Reversibility and deletability are actually features of most systems. Scales without bound is cool, but generally lacks use and is expensive. I would rather scale to my actual usage bounds rather than paying for infinite scalability. Composed without restriction is cool, but I got that with the MIT and BSD licenses. Forked and restricted has already been possible using traditional open-source computer infrastructure.

rapind 4y ago

> It could be world-changing (at least for programmers). If you don’t mind, could you give an example for a programmer who isn’t building finance or crypto related applications? I think that would help me understand what we’re talking about.

pjkundert 4y ago
https://twitter.com/pjkundert/status/1590009435619217413 https://twitter.com/pjkundert/status/1590009435619217413 The clutter.social App is a decentralized Twitter-like app implemented on Holochain. This one is hosted on https://holo.host https://holo.host (only in public Beta, so it doesn't scale automatically), but illustrates a full-complexity app that is deployed. You can compose this (eg. re-skin it, or build it into another app as a commenting back-end), without having to copy the implementation or host the data. You can also "clone" such an app (with or without any functional changes) and host that fork yourself (eg. on a company’s or family's computers), and nobody can stop you.
- dnissley 4y ago
  Who pays the hosting bills for the app? If whoever is responsible fails to pay the hosting bills, presumably the app will cease to function and perhaps even disappear? When I fork it, do I maintain my ability to communicate with users who live on the "source" app?
  - pjkundert 4y ago
    The App's current owner(s) pay, of course. For traditional "installed" Apps, this could easily be the current (and new) end-users of the App. For a purely hosted app (eg. an App that serves web clients), hosting must be arranged. If the App has no revenue model to pay for hosting, perhaps don't use it (embed it) within your app? That would be a risk. If you "fork" it, then you're responsible to host it -- if it isn't hosted by each client App installation already. The "forked" version of the App hosts its own DHT, so its data is completely distinct from the original. So, yes: there are decisions to be made, but they revolve around long-term viability of the encapsulated/forked App -- not the fundamental possibility of doing so.