Assumptions Problem 1: We currently create a bloom filter with size proportional to number of historical DhtOps and exchange it while gossiping. Ideally we would take up less space for older data that is unlikely to change. Problem 2: We create one of these bloom filters for each peer we gossip with, because each peer's DHT Arc has a unique overlap with ours. Ideally we would have less unique overlaps, so that we could re-use computation. If we align our DHT Arcs along predictable boundaries and split the Arcs into chunks, we can re-use gossip data for a given chunk across each connection that has that as overlap. If we compute hashes of historical DhtOps for various time ranges, we can gossip those hashes instead of a bloom filter, and in the frequent case where those hashes do not differ between peers, we can save resources. We want to optimize gossip to accomplish a few main goals:be easy to maintain (follow a single pattern in a single gossip loop) minimize overhead in terms of computation and bandwidth require the most reliable nodes to do be doing the least work (meaning, a node that has been offline knows it is going to have to get updates when it comes on, but nodes that stay on, should only be computing and gossiping new data, never old data with each other) Overview

This is still rrDHT, but playing with the name qDHT just to talk about the new structure of things, which is essentially a Quantized DHT. Design Original chunks+fingerprints doc DHT as Spacetime, and using Fenwick trees to represent spacetime regions Choosing space and time quantum size Choosing "chunk size" (one factor in the overall question of partitioning the arc) Choosing a partition of the arc area (very WIP) Arc resizing in quantum space Patent planning

Event Checklist | Retrospective Template | Event Overview | Event Marketing | Retros | HC Online Events Directory Event Checklist Pre-Show [x] Hosts arrive 15 min early for prep. [x] Make this event checklist look fresh (and make any revisions that you were meaning to get to but haven’t yet) [ ] Any Q’s from Discord ?-q-and-a-beginners channel? Recent changes? [ ] Who is going to open the session? Close? [ ] Attendees arrive in zoom waiting room. [ ] Hit Record (cloud recording) (if in a medium where we can record)

Event Checklist | Retrospective Template | Event Overview | Event Marketing | Retros | HC Online Events Directory Event Checklist Pre-Show [ ] Hosts arrive 15 min early for prep. [ ] Make this event checklist look fresh (and make any revisions that you were meaning to get to but haven’t yet) [ ] Any Q’s from Discord (????) channel? Recent changes? Add them to The Show agenda below. [ ] Who is going to open the session? Close? [ ] Attendees arrive in zoom waiting room. [ ] Hit Record (cloud recording)

Context We need to provide simple mechanisms to make it easy for Holochain app devs and hApp providers to protect against Sybil attacks (i.e. creation of lots of sock-puppet nodes to overpower a DHT network). The easiest way to do this is to allow hApp publishers verify ownership of a phone number or email address and let them limit accounts per such identifiers. The launcher and HoloWeb SDK will be coded to enable service requests that generate membrane proofs based on user data, i.e. joining codes, secrets, etc. NOTE: this document is written as if Holo was going to provide the actual receiving end of the API and thus is a "turnkey" service for application providers so they don't have to. For beta (at least) we wont do that, but we DO want to provide the API so that application providers that want this service can setup up joining proof servers that can handle both immediate proofs or round-trip confirmation proofs for email/sms type options. Assumptions The identifying key that has a clear owner in another "world" (i.e. email address, ETH key, DID) must be validated as under the control of the agent requesting it's use. For example email confirmation link clicked, Signing of some data with the ETH Key, etc The membrane proof created will be self-proving, i.e. the genesis function can check a crypto-signature against a key that get gets from the DNA properties. There can be exceptions to this but it make validation much harder, and likely not possible during genesis.

Event Checklist | Retrospective Template | Event Overview | Event Marketing | Retros | HC Online Events Directory Event Checklist Pre-Show [ ] Hosts arrive 15 min early for prep. [ ] Make this event checklist look fresh (and make any revisions that you were meaning to get to but haven’t yet) [ ] Any Q’s from Discord (????) channel? Recent changes? Add them to The Show agenda below. [ ] Who is going to open the session? Close? [ ] Attendees arrive in zoom waiting room. [ ] Hit Record (cloud recording)

Event Checklist | Retrospective Template | Event Overview | Event Marketing | Retros | HC Online Events Directory Event Checklist Pre-Show [ ] Hosts arrive 15 min early for prep. [ ] Make this event checklist look fresh (and make any revisions that you were meaning to get to but haven’t yet) [ ] Any Q’s from Discord (????) channel? Recent changes? Add them to The Show agenda below. [ ] Who is going to open the session? Close? [ ] Attendees arrive in zoom waiting room. [ ] Hit Record (cloud recording)

Opening the terminal: To start, open your terminal application. On macOS, you can find it in the Utilities folder within the Applications folder, or by searching for "Terminal" using Spotlight. On Linux, it may be called "Terminal", "Konsole", "Gnome Terminal", or similar, depending on your distribution. Displaying the current directory: To see the current directory you are in, type the following command and press Enter:pwd Listing files and directories: To list the files and directories within your current directory, type the following command and press Enter:ls To view hidden files and directories as well, use the -a option:ls -a Changing directories: To change to a different directory, use the cd command followed by the directory path. For example:cd Documents To move up one directory level, use the .. notation:cd .. To navigate to your home directory, use the tilde ~ notation:cd ~

App Info/Settings UI Password UI password can be set, updated and revoked for an app Different UI Viewing modes UI can be opened in a more secure tauri window (probably default) UI can be opened in a browser More than one UI per app Option to install additional UI's to an existing app

Step 1: Export CSV File from LastPass (All OSs) Go to the LastPass login page at https://lastpass.com/?ac=1 Enter your email address and master password, then click Log In. If prompted, complete steps for multifactor authentication (if it is enabled for your account). Based your navigation pick one option: Select the Account tab, then go to Fix a problem yourself > Export vault items. Select Account Options OR < your username > at the bottom of the menu, then go to Advanced Options > Export. If prompted, enter your master password. If desired, select Do not re-prompt for and use the drop-down menu to select a time interval.

Setup your cryptography Step 1 Holochain is a next gen cryptographic app that uses cryptographic keys for everything, but keys are not easy for humans to remember, so we allow you to set passwords to access important keys needed to use apps.

Encrypt your local databases (the password we already set for launcher)
This password will be needed every time you run Holochain via Launcher. Do not lose it, there is no way to recover it and you will need to reset Launcher with a new password, which will delete all your existing data in any apps you have installed. Set your holochain password Launch Apps in a pre-authenticated browser window (this may not have all the features you expect in a browser)
or
Launch Apps in your system default browser. This requires an additional password. Set your UI password Advanced: Backup Your Keys Next Step 2

hackmd-github-sync-badge ⚠ DEPRECATED ⚠ This document is deprecated. The source-of-truth for project management of MewsFeed is now on github: https://github.com/orgs/GeekGene/projects/1 Background During the early days of Holochain development in 2016 and 2017, members of the team decided to try building MVPs of commonly used platforms on the prototype version of Holochain. Among those was a Twitter clone we called "Clutter," themed around cats instead of birds (because cats eat birds). And because a Clutter or Clowder is the groupname for a bunch of cats. It worked well enough to play with at hackathons, and give occasional demos, but never became a full-featured affair. Original Clutter UI

Reviewer: Least Authority Series of Scopes in Security Review Process SCOPE 1 -- Lair Keystore Goal: Assess that there is no private key leakage from this tool set for key management, and no attack vectors via API for accessing private keys and that permissions are enforced. Overview of Lair Keystore Holochain's secret lair is where secrets are kept. It is the secure keystore which holds private keys and seeds. Private keys should be encrypted at rest, only load to crypto-protected memory, and never leave lair, therefore lair performs any and all cryptographic functions which need to use private keys, for the various Holochain subsystems which need decryption, encryption, or signing.

The purpose of this change is to allow user to change a primary point of contact. All previously registered code / pubKey remain connected to the email that was a primary email at the moment those code were created. Basic requirements: user should be able to change the email via UI user needs to confirm new email address via email if user does not have access to new email, their account should be able to roll-back to their existing email only someone with access to the account can confirm the email change (i.e. if the new email belongs to a different person, they can't click the link to confirm the change) Until the email change is completed, your current/old email continues to be valid

Phase 2: UX CLI nix-shell https://holochain.love --run "hc scaffold gui" npm init @holochain # Brings up the UI, scaffolds app with the latest holochain version (hdi crates version??) and sets up nix and cachix npm init @holochain my_project --ui vue # Scaffolds a full app already with vue either:

This update contains significant breaking changes to the api. We're aiming for these to be the last breaking changes before beta, so hopefully you won't have to do another migration like this anytime soon. The intention of these changes is to bring the web-sdk api more in alignment with @holochain/client, which will also be getting an update soon to bring the two apis even closer. Changes There are three major areas of change zomeCall renamed to callZome Anywhere you currently have client.zomeCall, replace it with client.callZome callZome results changed

Context We need a public facing hApp that will be tightly integrated with the Launcher to let end-users pick hApps to install on their machines. Holo needs a hApp that publishers/proividers can pick from to start publishing/providing hApps Assumptions We need a distributed app for distributing happs The hApp store is targeted to end-users, to enable them to install apps. The hApp store will be integrated with the Launcher

Crucial concepts DHT as spacetime plane Space: Transition rrDHT arcs to have discrete boundaries and build a space tree of blocks Time: Setting a $T_0$ for each app/DHT and building a time-tree of time blocks Can compute a hash (via hashing or XOR as an optimization for unordered data and compression of "stable" tree branches) of all hashes of all data in any region of spacetime Useful concepts

Assumptions & Requirements Purpose: This app serves to create namespaces for other Holochain apps and guarantee uniqueness of name registration within a namespace on a first-come/first-served basis. It manages rivalrous data. Light Consensus confirmed by 3rd party timestamping: We identify "first-come" based on a lightweight consensus built into countersigning, verified by independent signed timestamping of the hash of a name record. That hash gets sent via RoughTime protocol to (maybe 3?) roughtime servers who report their time and sign their response including a nonce from the request (which happens to be the DHT hash of the name record). We consider the "official" time to be the average time of the time servers who signed it. Easy Interoperability with other DNAs: The app should maximize ease of interoperatiblity for Holochain apps that don't want to deal with the issues around enforcing uniqueness of rival data. Non-rival namespaces for rivalrous names: A namespace is identified by: DNAhash and can be subdivided into NameTypes.... for which unique names will be be ensured (maybe name def must provde a regex for allowed characters and structure?) Matching hashes across apps: This app will ensure name uniqueness of Rival path entries, and co-function with a plug-in zome in other DNAs that store identically structured path entries and rely on this app for their registration and processing. For determinism, this design relies on "majority countersigning" (which is being added to Holochain countersigning and will initially have a max of 15 signing counterparties) in both the Service DNA and client namespace zomes. hApp name: Rival (for consensus on rivalrous data)

Approach DHT topology: spacetime cylinder We can think of the entire DHT topologically as a cylinder, with the space axis wrapping around itself, and time extending along its length, with the base fixed at the beginning of the network, and the other circular edge forever extending into the future. All ops exist somewhere on this cylinder. For the purposes of talking about the necessary concepts, it helps to unravel this cylinder into a simple plane, but just remember that topologically, the ends of space wrap around: The X's in the figures are where ops are located in space and time. (ha, I just noticed the typo, "opology", which is also appropriate, but that should be "topology") Our DHT storage arc is simply a 1-D space interval, which describes a lengthwise strip on the cylinder, or a vertical strip of spacetime (two strips if the arc spans the origin). Thus, the storage arc describes a large rectangular region of spacetime.