not without Ceptr
not surprising they dont have a whitepaper
exactly.
aka not fully distributed (although neither is HC in the beginning) however HC is the only available framework for getting to that point – at least that I’ve seen, if anyone finds another please lmk
would love to get Phillip Beadle and Stephen Alexander in on this convo
and dare I say, Eric…
as the backend currently stands, can we fractally divide membranes? I want to build a Happ within a Happ within a DNA bundle
beautiful!
not via linear DAG I hope
lovely 
great idea, this highlights the smart “agent” concept… think of them as decentralized autonomous oracles (reCeptrs ^^)
Oh feels like a great idea. There definitively are ways and solutions for everything. The challenge is that we have to think out of the box because we have so much been used to client-server development
Oh, just this sentence makes me grasp more of HC, and get an essential point that I already but now get : the resilience, robustness and availability of the network growth with the number of peers ! Thank you 
I will read with attention your article
And the fact that HC works on a consensus amongst a sub-set of peers and we "eventually converge on an approximation of the truth” makes HC not relevant for holding a currency and financial transactions does it ? and the focus of HC is to build dApps, not to be a new currency. So if we want to include financial exchanges on a hApp, we would then integrate with another blockchain for that ?
Feels great
A Solid app does run on your internet browser, however it is a serverless frontend app, so there is no connection to a server for connecting to data, but direct connection to the pods from the browser. hApps don’t run in the browser ?
Yes I guess we have to be clever 
and indexes are key. and double sided relations.
for instance, for posts and comments :
on a classical database backed application, your post has many comments, the FK is on the comment, the post data table does not have any knowledge of which comments are connected to a post. You get the post and the comments by doing a join query between the post table and the comment table. On a dApp, you have to store the link to the post on the comment data, but also the link to the comments on the post data. Because otherwise, when you display your post, you would have to scan all the peers to ask them if they have comments for your post… It is pretty boring and time consuming work to do for a developer to properly manage all the relation keys in all directions. And yet these patterns are clear, this is where low code development and code generation can dramatically help ! This is just an example, I don’t know if it fully applies in HC where there is also common shared data. But on SOLID there is no share data : the data is supposed to be stored on the pod of the author, thus bringing this challenge I am talking about. And with SOLID, storing key to comments on post is, to me, already a violation of SOLID principle saying that every user owns his/her data and can revoke access at any time. It is not anymore fully true with these double sided relations because the knowledge that user X commented on post of user Y remains on user Y pod even after user X revokes access (the content is not anymore known, but the knowledge that user X commented is, which is also personal data)
But this example to bring here light to the benefits of low-code approach : we can figure out patterns to optimize performance, improve durability or whatever else we need, and then abstract them in code generation templates to benefit from low code development. And these patterns can be complex, this is not an issue because it is then automatically generated as many times as possible. However, with no low code approach, it would not be viable to have complex patterns because it would be too time consuming for a developer to develop over and over for every single case.
Heh, here’s where the waters get muddy. In reality, a PoW blockchain can only make probabilistic guarantees too – you’re basing your confidence on the faith that someone with a lot of mining power isn’t going to come along and mine a heavier chain than the one that is currently ‘official’. As far as I understand, the only blockchains that can make deterministic guarantees are the permissioned ‘classical BFT’ blockchains that require a vetted list of validators who commit each block by gaining 2/3 supermajority approval. And if you absolutely need that kind of surety, then you might be better off with one of those blockchains (or building one on Holochain, which shouldn’t be impossible).
For most real-world applications, though, probabilistic should be just fine. You can see a few graphs in the linked article that show that, with a good-guy ratio of only 50% network nodes, which is pretty terrible, you only have to contact 7 of your peers to be 99% sure of getting a ‘true’ answer about whether a past financial transaction was valid. That isn’t all that painful. Even if there are only 25% good guys, you still only need to contact 16 peers. That’s because the bad guys don’t have any control over who you choose to consult. Holochain is based on the idea that, when you have lots of computers witnessing data and freely talking to each other about what they see, it’s just too difficult to keep fraud a secret.
When only 10% of the nodes are honest, then you’ve got a problem… but it’s a problem of inefficiency, because it’s not that the it’s broken as with a 51% mining attack; you just have to do a lot more work to be 99% assured of finding an honest validator – you have to contact 43 nodes, to be precise.
You could go to a blockchain at this point, but I think it’s a lot cheaper just to prevent the proliferation of Sybil nodes. Small networks could do this via some sort of non-invasive proof-of-identity; larger networks with open membership could require each new node to submit a proof-of-work (say, 30 seconds difficulty) which would be mildly inconvenient for real people but really painful for Sybil generation.
@thedavidmeister goes into some other details that, in sum, make it really bloody hard to get away with fraud in a peer-witnessing network.
(Sorry if that was too much information; I’ve just been writing and thinking about it a lot lately and really enjoy geeking out on it 
)
The front end of the hApp can – back-ends run in the Holochain runtime on the user’s machine; clients can be done however you like (I see a lot of people doing single-page serverless web apps).
Sounds good – code generation seems to be really valuable for advanced devs, too, who don’t want to have to write the same boilerplate over and over again and worry about whether they got it right. I admit that, in a graph database, having to manage your own referential integrity between relations could be a real pain.
Yeah, and that underscores a concern I have about data pods too. We talk about data sovereignty, but what does it really mean? There’s a lot of information that I can say is unambiguously “mine”, like the embarrassing and vulnerable entry I wrote in my journal last night, but most information I produce is actually “ours” – social graph data, financial transactions – even government-issued ID is reflective of a relationship. Not sure how Solid tackles that issue – both the ontological difficulty and the inefficiency. I haven’t looked into it deeply enough.
Once again, I’m loving your vision and your wisdom; thank you for showing up and bringing your gifts!
Wow, these are some amazing developments HC is like web 4.0 if you ask me
Can’t wait to have the opportunity to play around with some of these tools!
geek out all you want brother, makes me feel less awkward
and so for the sake of that theme, I’m just gonna come out and say it…
blockchain is obsolete
infeasible
and most importantly, terrible for the environment!
I’m tired of the tribalism and the pressure to ‘walk on egg shells’
Should society not be able to speak up about flaws in technology?
Why would a network that gets more difficult over time ever be considered a good idea??
I will say it for those who can’t: Bitcoin is worse than worthless. Should be - $'s
The cliche of “work smart not hard” exists for a reason…
I am manifesting the day when the world wakes up and stops getting scammed by Game A elite ponzi
I would be ok if we removed the word “chain” from the brand
guess its too late bc of Holo… maybe call it HoloWorld haha play on words ^^
Even better, HoloGame! Or perhaps, SoloGame! Haha!
After all, it’s all just a game…
It is not too much Thank you for taking the time to sharing all this, this is very valuable, I can feel more Holochain now, getting bit by bit the spirit of it ! I believe that it is more than tech, it is a reflection of the state of our evolution as human beings and the mirror of the rising of our consciousness, through technology as a matter of fact. My intention is to connect to the subtle energy of it, so that I can be part of it, and bring my best by being of service.
This brings me to a friction there is with current low code technologies. It kinds of grows and there seem to be a huge market for it, and yet it is not fully flowing. Especially there is resistance in hard core developers to fully embrace low code, at least all the major platform we see emerging. The reason for me is that most of the low code platforms are quite black boxes, and developers like transparency, developers likes to be allowed to open the box, understand the mechanics. And it better be high quality amazing beautiful mechanics, because developers like beauty More than this : as developers we like to create, we are passionate artists, all we need are tools to accelerate our work and unleash our power. And current low code platform don’t allow for that. Current low code platforms are in fact limited in what can be created from them, mainly data centric, client server applications.
Also, the major low code platforms we see emerging are serving the old : they emerged from the current system to serve the current system. This is why it was important to me to open source Generative Objects, let go of my old customers and focus on bringing a new energy. Better said is : to refocus on my core initial intention and energy and bring Generative Objects with the intention of being of services of creating a new world.
I call Generative Objects (GO) a low code platform, but it is more than that. It is what I call Generative Code. In the sense that GO offers to the developer a fully open platform where he/she can actually play with every single detail, and create their own application meta-models and generation templates to model and generate any kind of family of applications on any target architecture and infrastructure. In fact : the developer will use the Core GO platform (which is low code platform for modeling and generating datacentric client server applications) to create another GO platform, another specific low code platform that will be used to create another kind of applications. For instance in our case : serverless Holochain applications. And so on, there is no more limits.
To summarize : the developers use GO to model and create the right low code platform for then end users to use to create a specific type of application. It unites developers and end users, everyone being in is highest excitement and joy, doing what they love with the most efficient tools.
This is actually possible because GO itself is self-reflected and is used to model and generate itself.
I believe that how we see data, sovereignty, mine and yours etc… Is still old paradigm. We are in the transition phase of a big shift. I foresee a world where we are truly one and where transparency, honesty, fearlessness and true sharing is the standard, and many of those things we are setting up to protect ourselves will one day vanish.
Oh thank you for receiving me, your words mean a lot to me. I am so grateful for this enfolding
Well Blockchain actually brought something precious and supporting a big shift in our way to envision the world, and made decentralization of finance actually possible, which is dismantling a pretty big piece of the old ! That’s priceless.
And yet this is just a step, a spark in the universe. I like your energy, we ought not to put on a pedestal any one or anything as who/what will save us. But stay in awe about what was created and be curious about what is coming next, knowing that nothing is permanent, all will pass, which bring the excitement for this highly creative process !
And I don’t really like hearing “yeah that’s ok that blockchain is using so much power, anyway the current financial institutions are directly or indirectly using more”. Well, that might be true but : sorry … not good enough ! We are much more powerful than that, we can move beyond this energy consumption level
Thank you @The-A-Man, @guillemcordoba for the pointers,
I have watched the CRISPR videos. I remember now @artbrock talking to me about CRISPR when we had a talk around Holochain, low code and Generative Objects.
For what I see, it is a low code platform dedicated to HC apps, and as such it talks HC language and is fully tailored and built for HC apps. And I don’t see (at least from the demos) the aspects and separation of concern for application metamodel, generation templates and generated application. Which makes sense since there was not necessarily a need for it.
Generative Objects (GO) is a generic model driven platform that can be used to model and generate any kind of application, by giving full control on the application metamodel, code generation templates and generated code, and can target any output language, therefore it can talk RUST and HC. As such, it allows to easily build very high-level end user modeling interfaces (the CRISPR interface still feels to me targeted to tech aware people), and to be able to easily enrich and improve the level of functionality that can be modeled and generated by improving or writing new application metamodels and code generation templates.
What I could do, is to prototype the integration of Holochain with Generative Objects by adding the relevant code generation templates, still using the existing GO application metamodel, with a few tweaks if needed. I could build on top of the generated code from CRISPR and extract code generation templates from there.
Before doing this, I would like the confirmation that it is actually relevant and could serve the HC community. Then I might need some support in understanding some of the details of HC apps and architecture.
@philipbeadle what do you think about this ? How do you feel about partnering in this direction ? I would love if the GO platform could be serving you to bring CRISPR even further !
Don’t know about others, but it would definitely serve me. You’ve got one customer, dude!
Go for it!
Indeed! In fact, even I at times find CRISPR intimidating… [Never worked with the web-stack: HTML, CSS, JS, Vue, what have you… I hate scripting languages (and all those frameworks that at the end produce (HTML, etc) scripts. Absolutely loathe them! But CRISPR (or Builder, whatever you call it) seems to have married to Vue&Vuetify. So it’s great that your G.O. isn’t (theoretically) locked to a certain U.I. framework; that’s the beauty of abstracting away generation-code (as you said); it’s a good design-pattern. So it’s sort of comforting that G.O., the way it has been architected, would at all time be future-ready (unlike CRISPR; citation needed)! The world is changing at breakneck speed; can’t say about next year, but I’m pretty damn sure that by the next decade, scripting-languages won’t survive; Holochain will (thankfully; which is why we’re all here, right); and as for the User Interfaces, I guess all our interactions would be taking over V.R./A.R./X.R. targeted applications, built statically as a binary for the respective hardware; sharing scripting languages was great when internet (as we know it) wasn’t a thing, but with 5G, StarLink (and the likes), etc, its ridiculous to think that we would still be sharing browser-baked scripts (like HTML/JS); not only do they restrict the amount of flexibility in what sort of output (webpage, VR experience, or whatever) you can produce, but also they cost more in transfer; I mean, there’s a limit beyond which sharing scripts becomes more costly than sharing pre-built binaries, and if you want to build a web-experience that sort-of mimics (let alone rival) the sort of output that game-engines generate, then the code that produces that output would outgrow the binary-size that you’d have had had you chosen to go the pre-compilation path (thanks to build-compressions that we can leverage when producing binaries) by orders of magnitude! I’m not saying that you ought to be generating binaries for user-interfaces; all I mean is that it’s a great decision to keep it separate and abstracted so as to be doable in the late late future…]
Hey! So I think a lot of what you are talking about has quite a bit of overlap with features that Builder has, CRIPSR had but as far as I know it has been discontinued. I’ll ping Philip about this, maybe the best thing is to integrate and join forces?
Thank you !
I find it to be a good choice amongst stacks available today : open source front framework of great quality, great community and … independent ! Not like REACT for instance, which is created and controlled by Facebook who already once tried to tweak the license … VueJS and Vuetify is also a choice with GO for the new tech stack we are integrating in our default generated architecture. And still : you are not locked with it as anyone can create his own architecture and generation templates anyway, targeting any tech / language.
Yes indeed, it is a modeled driven environment, models and generation templates can be evolved or full new models can be created, to target new technology stacks. The beauty is that the functional application model does not change, so you can regenerate all your applications portfolio to new tech stacks, in the click of a button.
Yes indeed !
I would love to see a demo of Builder.
Oh yes for sure, the idea to me is to join forces ! Especially when we have strong shared values. I am more than happy to bring all I have done over the last 12 years at the service of the Holochain community. And see how that can fit and be integrated, using the best of each part.
As far as Builder demos go, here’s an entire youtube playlist on it:
Walter - fascinating discussion. I would like to get an update on where this hApp low code effort stands. I am a technology competent non programmer looking at HC for Aging at Home enabling solution. GO seems like something limited skills folks like me who want to build hApps should look at.
Sounds awesome brother! Myself and @walter.almeida have been talking a lot about Low Code Solutions for Holochain for sometime now, as you all may already be aware I have been working on the .NET HDK for just over a year now and it started of as a Low Code Generator, which worked in a similar way to GO, in that it used C# and Rust templates to dynamically generate C# and Rust code.
This was built on top of HoloNET (the .NET and Unity Client I built back in 2019), so the C# code it generated had HoloNET integrated into it, which called into the dynamically generated rust code. This was all working fine and was about to release last Sept when RSM was announced so I decided to hold of. Unfortunately, it has taken nearly a year to get RSM working on Windows, so this is what has delayed me releasing the .NET HDK.
But the good news is this gave me time to refactor and improve the .NET HDK and also integrate it with the OASIS API so it is now de-coupled from Holochain and can generate dynamic native code for any OASIS Provider (currently supports Holochain, EOSIO, Telos, SEEDS, Ethereum, IPFS, Neo4j, MongoDB and SQLLite). It then evolved into the STAR ODK (OASIS Development Kit).
This allows users to debug their Holochain apps in C#, something they cannot do in Rust. It splits out the BLL (Business Logic Layer) into C# and the DAL (Data Access Layer) into Rust. It also allows you to build and publish your hApp using HoloNET (has the Holochain Conductor built in) so the user never needs to worry about the conductor or even touch any rust if they did not want to. Of course, people can customise the C# and Rust code that is generated as well as edit the templates it is built from (CRUD).
Also, the generated hApps have the conductor integrated, which is automatically started and stopped by HoloNET (one of its many powerful features) so they do not need to worry about shipping and configuring the Conductor separately.
STAR ODK can do a lot more on top of this, soon I will also be adding the ability for it to compile into WASM (Web Assembly) as well as run Holochain in a browser fully integrated with client side WASM so it will be full stack WASM running in a browser!
I have just got the Windows binary working after waiting patiently for 2 years so now that has unblocked me once again to release HoloNET RSM followed by STAR ODK/HDK hopefully not too far behind.
STAR ODK is modelled on the Omiverse itself so contains Multiverses, Universes, Galaxies, Stars, Planets, Moons, etc. The first OAPPs (OASIS Apps) created will be Moons orbiting the first planet (Our World) and this is the beginning of the OASIS Metaverse you see in Ready Player One…
Read more here:
You can for example have a Holochain Galaxy, EOSIO Galaxy, Ethereum Galaxy, etc where they all interoperate including cross-chain smart-contracts even within Holochain… this is the grand vision I have held for many years now and now it is all coming together… I hope to release STAR ODK within the new few months.
The OASIS API was released last Oct as a REST API:
http://api.oasisplatform.world
So, it can already be used to build OAPP’s with for devs. STAR ODK will open the doors for non-coders to also build OAPPs as well as bridge Holochain to every other network and the massive unity, c# and enterprise sectors. STAR can generate apps, websites, games, services, basically anything that has the templates created for.
We have just taken on 8 web devs to help finish the UI to the OASIS API here:
We have also just taken on 3 devs to help finish the Our World AR Geo-location prototype built on Holochain and the OASIS API. We also have taken on 3 C# devs to build out more of the OASIS Providers including ThreeFold, ActivityPub, COSMOS, Ultra, Solana and others… so lots happening, and things finally are speeding up now, yay! 
My mission is to integrate everything to everything to remove all silos once and for all, it is unity consciousness expressed within the technical sphere…
One of the main goals of the OASIS API is to help create bridges to Holochain from everything else allowing quicker and easier migration paths to Holochain… Also, once you have built your OAPP you never need to worry about upgrading to the latest version of Holochain or porting to yet another tech stack where you need to keep learning new languages, tools, etc. The OASIS will handle all this for you by continuously adding OASIS Providers to connect to everything else.
It also had auto-fail over so if one node on one network goes down it will automatically switch to the next fastest node in your area regardless of what network or platform it is running on. It also has auto-load balancing so you will always get the fastest speed possible utilising the power of ALL the networks (eventually the entire internet). It also has auto-replication, so your data is auto-replicated across networks for maximum fault tolerance. You also have full control of your data as well as owning your data so you control what is shared and where.
Finally, it gives a SSO across all the networks using the Avatar/Karma system so you no longer need to remember countless passwords, etc.
Read more here:
As you can see this has some overlap with GO, which is why I am keen to integrate GO with STAR ODK, can you imagine how powerful both would become then?! GO has more work done on building the web app UI’s along with relevant workflows and business logic so this will save me time not having to build that part as I had originally planned… this will free me up to focus more on the interoperability parts, which is my area of speciality.
I also hope to integrate CRISPR and anything else that can enhance the platform. The whole is greater than the sum of the parts…
The future is bright…
The future is Holochain…
Much love & blessings,
D.
