I’m new to holochain development and am curious what possible benefits can be gained from building a board game app with a ranking system on holochain.
Also what would be more difficult on holochain? Like maybe timers?
If anyone else is working on a Go/baduk app I’d love to know. I know it’s more popular in asia.
Sounds like a fun idea! What benefits could be gained… I think the most pragmatic benefit is the fact that you aren’t dependent on the uptime of a central server and the potentially shaky business model that keeps it running — the app is the infrastructure
Of course there are tradeoffs to consider, like the fact that the framework is still in development, and that it’s always been difficult for peers in a P2P network to find each other without a bit of centralisation.
Provably accurate timers would definitely be harder — one idea is that players could elect a ‘judge’ node that receives copies of the moves and timestamps them. I’m sure there are other ideas!
@pauldaoust thanks for the response. I’ve been looking through a ton of holochain resources to try to come up with ways that I want to design happs. Turns out there was a dev camp on games GitHub - willemolding/generic-game-holochain: Checkers, tic-tac-toe, connect-4. These are all the same right? A framework for two player, turn based, perfect information games on Holochain.
I agree that not needing a central server is probably the main benefit. I never thought of judge nodes
Going through the core concept tutorials was interesting. I feel like I have a better grasp of what holochain can do. The marketing of holochain though really did confuse me, compared to looking at actual code. Even though I’ve done a decent amount of reading on social ecology, bottom up type structures and philosophy, I still don’t understand what you guys mean by no absolute truth or agent centric. At least I don’t get how all these metaphysical ideas relate to happ developers specifically (It makes a bit more sense to me as it relates to holochain core devs).
@Alexr1239 thanks for the feedback on the woo-woo-ness of the whole ‘no absolute truth’ thing as it relates to app dev. After trying to digest it over the past two years (and getting indigestion a few times) I think I’ve got a half-decent grasp of the consequences for devs and UX… I want to write an article on it, but in the meantime here’s my take:
- It costs energy to keep information in coherence, because entropy is always chipping away at it (cf Claude Shannon’s information theory).
- The more copies of a piece of information there are, the more energy it takes to keep it in coherence across all copies. In a distributed system, entropy takes the form of interrupted communication, synchronisation issues, hardware failures, and malicious agents.
- Therefore, you have a few choices:
- Choose one canonical source of information and discard all other perspectives. This is the cheapest, and is appropriate whenever there should be a single authority. Server-based systems choose this because simplicity and control.
- Coordinate everyone so that they have the same information, often at great energy cost. For systems that don’t involve malicious actors, this requires a Byzantine fault-tolerant coordination protocol that can tolerate 1/3 corruption. For systems that do involve malicious actors, you need to go one step further and introduce economic penalties for intentionally introducing entropy (corrupting the data set), namely proof-of-work or proof-of-stake. This is the approach that blockchain is taking.
- Embrace the fact that every node has a different perspective, and design systems that equip each agent to make their own decisions about the quality of the data they’re seeing. This is the approach that Holochain, Secure Scuttlebutt, Git, and probably others are taking. (I’d characterise all three as ‘agent-centric’.)
I think each has its place, but the thing I like about the third approach, the ‘agent-centric’ approach, is that it does a better job of reflecting how real life works — all we ever have is our own perspective, and the judgments we’re able to make based on the information we receive. Just like real life, it’s uncomfortably messy for those of us who are accustomed to predictability (I still struggle with the inherent messiness of Holochain’s data integrity model sometimes).
But I take hope in the fact that this messiness actually creates robustness — there’s no central point of failure. It works well for the natural world; mammalian immune systems are essentially P2P networks of cells that have mostly agreed to cooperate in identifying pathogens, spreading information about them, and coordinating attacks against them.
How does this apply to app development? Well, not much — it’s mostly to do with how Holochain’s ‘immune system’ identifies and suppresses bad actors. I guess it does leak through into the UX of the app in some ways though:
- The local-first-ness of Holochain means you can take yourself offline and your perspective on other people’s data goes with you.
- You own your data, not some company.
- It encourages app designs that reflect its uncertainty — why not allow a user to register multiple handles, or allow multiple users to use the same handle, or even allow my friends to assign their own handle to me?
- It gives you decentralised data management without the performance overhead of blockchain.
“The local-first-ness of Holochain means you can take yourself offline and your perspective on other people’s data goes with you.“
hmm so maybe what I don’t get is this idea of different perspectives. From the happ developers view point, the data is stored somewhere, how this is done is abstracted away from us. Same for the user. So from a high level there’s really just private information for each user, and then a commons for information.
So each user doesn’t really have their own wholly unique perspective. Maybe if each person had their own generalized ui and combined dna in different ways, i could see that amounting to a perspective.
If you guys said node-centric or something more low level sounding I’d buy it more. Agent-centric to me kind of implies new design opportunities for distributed app developers or new kinds of experiences made possible for users.
Honest thanks for challenging me to be more rigorous about what I’m saying. I haven’t figured all this out yet, but I do sorta feel that there are benefits that show up to the app developer or user.
But yeah, I guess agent centricity is more about the low level and how data comes to consistency — it enables decently reliable coordination in the absence of a central server (which does have UX benefits re: uptime, privacy, and ownership). But to the app layer it either doesn’t matter or looks like clunkiness — why hasn’t my message gone through yet?! (I remember when Facebook switched to an eventually consistent database; it annoyed me that sometimes I could see posts and then they would disappear.)
I’m sure it’s just the way holochain is explaining its message overall. how you explained things is similar to how others are on the team. I can see it being difficult juggling multiple audiences. You guys have the users, the currency nerds, the techies and philosophers that all care about different things.
But yeah I definitely am curious about design patterns that are more reliable on holochain than across centralized servers. Definitely think modular designs will be the most interesting.
So I think learning from this conversation, I’ll want to focus on how to represent/interact with the game tree as one module. In go programs there’s always a tree that allows you to play out different variations that could have happened in a game. It could also just be used to represent an ongoing game. By separating this piece, different sites could spectate the same game using the same DNA.