DEPRECATED. The Holochain framework implemented in rust with a redux style internal state-model.

Related tags

Cryptocurrencies rust blockchain wasm dht dapps holochain
Overview

Holochain-rust

holochain logo

Project Chat

Twitter Follow

Travis: Build Status Circle CI: CircleCI Codecov: Codecov License: License: GPL v3

This code is loosely based on the previous Golang prototype.

Code Status: This Rust version is alpha software -- not for production use. You should expect unstable code APIs and data chains.

NO LONGER CURRENT REPOSITORY: This version of Holochain has been replaced by a version that is more performant, stable, and secure. We suggest porting applications to the new version of Holochain which is receiving regular updates and feature enhancements.

Find releases here.

Holochain Links: FAQ Developer Docs White Paper

Overview

Holochain-Rust Architectural Overview

Application Developer

Setup a development environment with the latest release to build Holochain applications:

https://developer.holochain.org/start.html

Core Developer

Setup a core development environment to work on Holochain itself:

Core Developer Setup

Documentation

API Reference

Auto generated documentation for all of the code written in Rust is published online, with different versions to match the releases here: https://developer.holochain.org/docs/api.

The Holochain Guidebook

There is a guide for understanding and developing with Holochain. It is published online, with different versions to match the releases here: https://developer.holochain.org/guide.

See instructions for how to contribute to the book at doc/holochain_101/src/how_to_contribute.md.

Contribute

Holochain is an open source project. We welcome all sorts of participation and are actively working on increasing surface area to accept it. Please see our contributing guidelines for our general practices and protocols on participating in the community, as well as specific expectations around things like code formatting, testing practices, continuous integration, etc.

Some helpful links:

License

License: GPL v3

Copyright (C) 2017 - 2020, Holochain Foundation

This program is free software: you can redistribute it and/or modify it under the terms of the license provided in the LICENSE file (GPLv3). This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Comments
  • [WIP] - New macro HDK

    [WIP] - New macro HDK

    HDK Improvements

    Rust edition 2018 allows for defining procedural macros. These allow for arbitrary transformations to be made to modules, functions and structs/enums at compile time. These were not available at the time the current HDK was created.

    This is used by popular rust crates (notable Serde and Rocket.rs) to allow simple DSLs. For example in Rocket.rs it is used to define which functions act as callbacks to HTTP reqests:

    #[get("/")] // example of an attribute-like macro
fn hello() -> &'static str {
    "Hello, world!"
}

    The flexibility of proc macros means there almost unlimited ways to define a DSL that makes zome development in rust as productive as possible with minimum boiler-plate. This PR serves as a place to discuss both what the HDK should look like from a developer perspective but also what is easy/possible to implement.

    Initial Proposal

    #![hdk::zome] // this attribute-like macro operates on the whole module. This is equivalent to define_zome! in the old HDK

#[hdk:entry] // instructs the top level macro that a entry should be created that maps to this struct
struct Post {
    content: String,
}

#[hdk:entry(validation = "validate_blog", validation_package = ChainFull)]
// provides custom validation callback and also an idea of how links could be defined
struct Blog {
    owner: Agent,
    #[hdk::links("posts")]
    posts: vec<Post>,
}

fn validate_blog(entry: BlogEntry, validation_data: ValidationData) -> ZomeApiResult<()> {

}

/////////////////////////////////////////////////////////////////

#[hdk::genesis] // genesis callback
fn genesis() -> bool {
	true
}

#[hdk::receive] // receive callback
fn receive() -> ZomeApiResult<()> {
}

// a zome api function that belongs to these two traits 
// (this maybe needs some discussion)
#[hdk::zome_function(traits = ["zome", "bridge"])]
fn get_posts() -> ZomeApiResult<String> {
}

#[hdk::zome_function(traits = ["plumbus"])]
fn delete_all_posts_idc() -> ZomeApiResult<> {
}

    Considerations:

    • It should still be possible to split entries/callbacks between multiple files
    • All of the customization of define_zome! must be supported
    • The GraphQL schema generation should be an extension that works on top of what is defined here
    WIP bikeshed? 
    opened by willemolding 37
  • [upstream issue] Warnings with nix on Manjaro Archlinux `warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels' does not exist, ignoring`

    [upstream issue] Warnings with nix on Manjaro Archlinux `warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels' does not exist, ignoring`

    These warnings are misleading as suggested here on the Discourse forum and can be ignored.

    warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels' does not exist, ignoring
warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels/nixpkgs' does not exist, ignoring

    They are the warnings that appear after uninstalling and reinstalling and entering the nix-shell (including by running nh):

    $ sudo rm -rf /nix /etc/nix /root/.nix-* /home/*/.nix-*
zsh: no matches found: /root/.nix-*

 23:32:53  ✘  jr@fm  ~/hcr  ⬡ v8.16.0  🦀 1.33.0-nightly   946-feature-chain-pair ✔ ⬆ 
$ sudo rm -rf /nix /etc/nix /home/*/.nix-*             
[sudo] password for jr: 

$ alias cn
cn='curl https://nixos.org/nix/install | sh'

 23:33:11  jr@fm  ~/hcr  ⬡ v8.16.0  🦀 1.33.0-nightly   946-feature-chain-pair ✔ ⬆  6s 
$ cn

$ . /home/jr/.nix-profile/etc/profile.d/nix.sh

$ alias nh
nh='nix-shell https://holochain.love'

$ nh
warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels' does not exist, ignoring
warning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels/nixpkgs' does not exist, ignoring

[nix-shell:~/hcr]$

    So it seems unnecessary with trying to fix the warnings by doing things like those listed in https://forum.holochain.org/t/ubuntu-and-debian-troubleshooting-brain-dump/1007. If they cause CI issues down the track that would be problematic, but that could be handled if the issue arises.

    Outdated:

    Tasks:

    • [ ] resolve being able run curl https://nixos.org/nix/install | sh on (Manjaro) Archlinux rather than installing nix from NixOS/nix#3154.
    • [x] update docs from curl https://nixos.org/nix/instal to curl https://nixos.org/nix/install | sh.

    To install nix, recently and just today I tried using curl https://nixos.org/nix/install from https://developer.holochain.org/docs/install/, however, that just outputted the script. So I then tried piping with zsh and sh: curl https://nixos.org/nix/install | zsh. I was then able to run nix-shell, however I found that on logging out and in I was no longer able to run it—the command wasn't found. So I ran yay -a nix 2>&1 | tee nix-install-yay.txt. The command appears to be stuck in a loop, with cycling between different errors: nix-install-yay.txt

    opened by jamesray1 28
  • Keypair Derivation (HC-dpki lib)

    Keypair Derivation (HC-dpki lib)

    Holochain crypto is based on NACL / libsodium.

    Keypair is a bit of a misnomer. It is more of a pair of keypairs. A holochain "keypair" is made up of both a signing keypair and a key exchange keypair for use in encryption. Both pairs are derived from a common seed.

    • signature keypair - crypto_sign_seed_keypair Ed25519
    • encryption keypair - crypto_kx_seed_keypair BLAKE2B-512
    opened by zo-el 21
  • Check currently installed version of Rust, offer to un/re-install (OLD: See #782)

    Check currently installed version of Rust, offer to un/re-install (OLD: See #782)

    o Properly export PATH (in case this is the first installation of Rust) o Use target-specific variables to select TOOLS/CORE_RUST_VERSION

    If the wrong version of Rust is installed, we can check and offer to replace it with one compatible with holochain-rust.

    opened by pjkundert 20
  • UnresolvedDependencies error should not actually be an 'err'

    UnresolvedDependencies error should not actually be an 'err'

    while running the nix-shell --run hc-app-spec-cluster-test bumped up to 8 nodes, we start seeing some erroneous behaviours.

    It seems to be affecting both workflow/hold_entry and workflow/hold_link.

    Some nodes successfully Hold the entry or link, while others don't, the ones that don't show:

    [C2] 2019-05-29 20:14:10 ThreadId(1):test-1: err/workflow/hold_entry: QmUFxhsmL1krv59jL9rRQBKj8Jn311Tpz95KjR7zKEariU is NOT valid! UnresolvedDependencies([HashString("HcSCitO5WWuzmbyf7sfBZp7Oq5Y58Wkq7wvMA4gP4r364ideWxQkpHjko4ndrni"), HashString("QmWY98zemN4Mi9A9SgmC8vQufaQUf5a13Xe81PfWDvvnn9")])

...

[C3] 2019-05-29 20:14:10 ThreadId(1):test-1: err/workflow/hold_entry: QmUFxhsmL1krv59jL9rRQBKj8Jn311Tpz95KjR7zKEariU is NOT valid! UnresolvedDependencies([HashString("HcSCitO5WWuzmbyf7sfBZp7Oq5Y58Wkq7wvMA4gP4r364ideWxQkpHjko4ndrni"), HashString("QmWY98zemN4Mi9A9SgmC8vQufaQUf5a13Xe81PfWDvvnn9")])

...

[C4] 2019-05-29 20:14:10 ThreadId(1):test-1: debug/workflow/hold_link: invalid! UnresolvedDependencies([HashString("HcSCitO5WWuzmbyf7sfBZp7Oq5Y58Wkq7wvMA4gP4r364ideWxQkpHjko4ndrni"), HashString("QmWY98zemN4Mi9A9SgmC8vQufaQUf5a13Xe81PfWDvvnn9")])
2019-05-29 20:14:10 ThreadId(1):test-1: err/workflow/hold_entry: QmUFxhsmL1krv59jL9rRQBKj8Jn311Tpz95KjR7zKEariU is NOT valid! UnresolvedDependencies([HashString("HcSCitO5WWuzmbyf7sfBZp7Oq5Y58Wkq7wvMA4gP4r364ideWxQkpHjko4ndrni"), HashString("QmWY98zemN4Mi9A9SgmC8vQufaQUf5a13Xe81PfWDvvnn9")])

...

[C7] 2019-05-29 20:14:10 ThreadId(1):test-1: err/workflow/hold_entry: QmUFxhsmL1krv59jL9rRQBKj8Jn311Tpz95KjR7zKEariU is NOT valid! UnresolvedDependencies([HashString("HcSCitO5WWuzmbyf7sfBZp7Oq5Y58Wkq7wvMA4gP4r364ideWxQkpHjko4ndrni"), HashString("QmWY98zemN4Mi9A9SgmC8vQufaQUf5a13Xe81PfWDvvnn9")])

    My test shows that we should see 16 successful Hold actions, but we only see 12, corresponding to these 4 which failed

    Reproduce

    Change the following line in /holonix/app-spec-cluster/src/test.nix:

    ( EMULATION_HOLOCHAIN_BIN_PATH=./.cargo/bin/holochain node ./app_spec/cluster_test/index.js 2 )

    to

    ( EMULATION_HOLOCHAIN_BIN_PATH=./.cargo/bin/holochain node ./app_spec/cluster_test/index.js 8 true )

    also change the timeout of 5 seconds in /app_spec/cluster_test/index.js from 5000 to 20000 to give it more time to complete and show you the results.

    Then run nix-shell --run hc-app-spec-cluster-test

    bug 
    opened by Connoropolous 19
  • Failing to compile futures-util-preview v0.3.0-alpha.11 (tag =

    Failing to compile futures-util-preview v0.3.0-alpha.11 (tag = "v0.0.3" in Cargo.toml)

    OS: Windows mingw64.

    I've cargo cleaned and cargo updated, still doesn't work. Nightly toolchain is up to date. Tried both tag = "v0.0.3" and branch = "develop"

    Cargo.toml

    [package]
name = "articles"
version = "0.1.0"
authors = ["marcusnewton1 <[email protected]>"]
edition = "2018"

[dependencies]
serde = "1.0"
serde_json = "1.0"
serde_derive = "1.0"
hdk = { git = "https://github.com/holochain/holochain-rust" , tag = "v0.0.3" }
holochain_wasm_utils = { git = "https://github.com/holochain/holochain-rust" , tag = "v0.0.3" }
holochain_core_types_derive = { git = "https://github.com/holochain/holochain-rust" , tag = "v0.0.3" }

[lib]
path = "src/lib.rs"
crate-type = ["cdylib"]

    Console output

       Compiling futures-util-preview v0.3.0-alpha.11 (https://github.com/holochain/futures-rs?branch=pinned-to-alpha-11#dd9acd0b)
error[E0308]: mismatched types
   --> C:\Users\Marcus\.cargo\git\checkouts\futures-rs-d2a1cd193ada173b\dd9acd0\futures-util\src\future\maybe_done.rs:110:18
    |
110 |         Pin::set(self, MaybeDone::Done(res));
    |                  ^^^^
    |                  |
    |                  expected mutable reference, found struct `std::pin::Pin`
    |                  help: consider mutably borrowing here: `&mut self`
    |
    = note: expected type `&mut std::pin::Pin<_>`
               found type `std::pin::Pin<&mut future::maybe_done::MaybeDone<Fut>>`

error[E0308]: mismatched types
  --> C:\Users\Marcus\.cargo\git\checkouts\futures-rs-d2a1cd193ada173b\dd9acd0\futures-util\src\future\fuse.rs:53:18
   |
53 |         Pin::set(self.as_mut().future(), None);
   |                  ^^^^^^^^^^^^^^^^^^^^^^
   |                  |
   |                  expected mutable reference, found struct `std::pin::Pin`
   |                  help: consider mutably borrowing here: `&mut self.as_mut().future()`
   |
   = note: expected type `&mut std::pin::Pin<_>`
              found type `std::pin::Pin<&mut std::option::Option<Fut>>`

error[E0308]: mismatched types
  --> C:\Users\Marcus\.cargo\git\checkouts\futures-rs-d2a1cd193ada173b\dd9acd0\futures-util\src\future\into_stream.rs:39:18
   |
39 |         Pin::set(self.as_mut().future(), None);
   |                  ^^^^^^^^^^^^^^^^^^^^^^
   |                  |
   |                  expected mutable reference, found struct `std::pin::Pin`
   |                  help: consider mutably borrowing here: `&mut self.as_mut().future()`
   |
   = note: expected type `&mut std::pin::Pin<_>`
              found type `std::pin::Pin<&mut std::option::Option<Fut>>`

error[E0308]: mismatched types
  --> C:\Users\Marcus\.cargo\git\checkouts\futures-rs-d2a1cd193ada173b\dd9acd0\futures-util\src\try_future\flatten_sink.rs:62:18
   |
62 |         Pin::set(self.as_mut(), FlattenSink(Ready(resolved_stream)));
   |                  ^^^^^^^^^^^^^
   |                  |
   |                  expected mutable reference, found struct `std::pin::Pin`
   |                  help: consider mutably borrowing here: `&mut self.as_mut()`
   |
   = note: expected type `&mut std::pin::Pin<_>`
              found type `std::pin::Pin<&mut try_future::flatten_sink::FlattenSink<Fut, Si>>`

error[E0308]: mismatched types
   --> C:\Users\Marcus\.cargo\git\checkouts\futures-rs-d2a1cd193ada173b\dd9acd0\futures-util\src\try_future\flatten_sink.rs:102:22
    |
102 |             Pin::set(self, FlattenSink(Closed));
    |                      ^^^^
    |                      |
    |                      expected mutable reference, found struct `std::pin::Pin`
    |                      help: consider mutably borrowing here: `&mut self`
    |
    = note: expected type `&mut std::pin::Pin<_>`
               found type `std::pin::Pin<&mut try_future::flatten_sink::FlattenSink<Fut, Si>>`

error[E0308]: mismatched types
  --> C:\Users\Marcus\.cargo\git\checkouts\futures-rs-d2a1cd193ada173b\dd9acd0\futures-util\src\stream\unfold.rs:99:22
   |
99 |             Pin::set(self.as_mut().fut(), Some(fut));
   |                      ^^^^^^^^^^^^^^^^^^^
   |                      |
   |                      expected mutable reference, found struct `std::pin::Pin`
   |                      help: consider mutably borrowing here: `&mut self.as_mut().fut()`
   |
   = note: expected type `&mut std::pin::Pin<_>`
              found type `std::pin::Pin<&mut std::option::Option<Fut>>`

error[E0308]: mismatched types
  --> C:\Users\Marcus\.cargo\git\checkouts\futures-rs-d2a1cd193ada173b\dd9acd0\futures-util\src\try_stream\try_for_each.rs:52:22
   |
52 |             Pin::set(self.as_mut().future(), None);
   |                      ^^^^^^^^^^^^^^^^^^^^^^
   |                      |
   |                      expected mutable reference, found struct `std::pin::Pin`
   |                      help: consider mutably borrowing here: `&mut self.as_mut().future()`
   |
   = note: expected type `&mut std::pin::Pin<_>`
              found type `std::pin::Pin<&mut std::option::Option<Fut>>`

error[E0308]: mismatched types
  --> C:\Users\Marcus\.cargo\git\checkouts\futures-rs-d2a1cd193ada173b\dd9acd0\futures-util\src\try_stream\try_for_each.rs:57:30
   |
57 |                     Pin::set(self.as_mut().future(), Some(future));
   |                              ^^^^^^^^^^^^^^^^^^^^^^
   |                              |
   |                              expected mutable reference, found struct `std::pin::Pin`
   |                              help: consider mutably borrowing here: `&mut self.as_mut().future()`
   |
   = note: expected type `&mut std::pin::Pin<_>`
              found type `std::pin::Pin<&mut std::option::Option<Fut>>`

error[E0308]: mismatched types
   --> C:\Users\Marcus\.cargo\git\checkouts\futures-rs-d2a1cd193ada173b\dd9acd0\futures-util\src\sink\with_flat_map.rs:105:18
    |
105 |         Pin::set(stream, None);
    |                  ^^^^^^
    |                  |
    |                  expected mutable reference, found struct `std::pin::Pin`
    |                  help: consider mutably borrowing here: `&mut stream`
    |
    = note: expected type `&mut std::pin::Pin<_>`
               found type `std::pin::Pin<&mut std::option::Option<St>>`

error: aborting due to 9 previous errors

For more information about this error, try `rustc --explain E0308`.
error: Could not compile `futures-util-preview`.
    opened by marcusnewton 19
  • Add chain-pair to prevent a header and entry mismatch

    Add chain-pair to prevent a header and entry mismatch

    PR summary

    Aims to close #946

    By changing EntryWithHeader to a ChainPair tuple struct (with getters etc.), and using a try_from_header_and_entry() as a constructor and not a new() constructor, this introduces a log of changes, and not only with renaming. (If people prefer I can rename back to EntryWithHeader, etc., however I made the change as I thought it would be best to make it clear that it is backwards incompatible, and it is also shows intent more clearly since the header and entry must match in a pair, rather than being any header and any entry.) The change also broke a couple of tests, since the header and entry in them didn't match, and these tests have been fixed.

    I also ran cargo fmt, using a recent nightly, rather than from within the next shell. I think this is why there are a lot of changes with formatting.

      hcr git:(946-feature-chain-pair) rustc --version
rustc 1.40.0-nightly (38048763e 2019-11-06)

    ~~Contextual notes: Please bear in mind that work has been much less productive and frustratingly slow as I'm yet to sort out connecting my desktop to the internet, and my laptop only has 4 GB RAM so is slow to use and compile and/or freezes, and adjusting the swappiness etc. hasn't been effective (high swappiness—too laggy, low—too freeze-prone). This is combined with fixing merge conflicts, and further compiling, adjustments etc. Admittedly I should've arranged switching to my desktop ASAP much more quickly, and not have tried to persist with the CI build and then the laptop for so long. I'm expected to have fixed, fast, fibre internet working on Dec 2 (rather than using mobile data), so can then switch to using my desktop!~~

    testing/benchmarking notes

    ( if any manual testing or benchmarking was/should be done, add notes and/or screenshots here )

    followups

    ( any new tickets/concerns that were discovered or created during this work but aren't in scope for review here )

    changelog

    • [ ] if this is a code change that effects some consumer (e.g. zome developers) of holochain core, then it has been added to our between-release changelog with the format
    - summary of change [PR#1234](https://github.com/holochain/holochain-rust/pull/1234)

    documentation

    opened by jamesray1 18
  • Ensure build of libsodium/rust_sodium-sys is documented in Makefile and works

    Ensure build of libsodium/rust_sodium-sys is documented in Makefile and works

    Presently, building libsodium and linking against the result fails on important linux platforms (eg. Debian), and it is not clear in the Makefile or elsewhere how to fix the issues. I've added some documentation to the Makefile to assist the developer in overcoming this obstacle.

    • Detail how to select system/pkg_config/download build approach for libsodium in the Makefile
    • Logs the selected libsodium version and/or build approach and builds rust_sodium-sys as a separate target, to isolate failures.
    • Remove an unnecessary logging of CFLAGS used to build libsodium, but add logging of selected libsodium build choice.

    By default, we'll download/build our pinned libsodium version, and try to log alternatives for the user if it fails (but this failure is not always detectable, because it builds fine but fails in the later linking stage).

    • [ ] I have added a summary of my changes to the changelog
    opened by pjkundert 18
  • #99 network abstraction layer

    #99 network abstraction layer

    Hey folks, there's still a bit to do, but I wanted to get this up as a WIP PR to start getting feedback.

    Please see the discussion @neonphog & I have been having on #99

    The big thing left is about clarifying how topological routing works within one transport and across transports. I'm working on that next.

    BTW fmt is busted again until we complete #149 so don't expect CI to be green.

    opened by zippy 18
  • Upgraded docker and Makefile

    Upgraded docker and Makefile

    Summary

    While I was moving the docker automated build to the holochain org, the build of our Dockerfile errored while installing clippy. It seems like clippy is now officially supported by the rust core team and inside the component collection of rustup. This means better support but also that I had to do some adjustments. As of this update we will be using:

    • nightly-2018-07-17 for our tools (rustfmt, clippy)
    • nightly-2018-06-01 for Wasm compilation
    • stable for everything else

    The upgrade of rustfmt again will result in some reformatting. I intentionally didn't include the changes of that because the changes will still have to go though the docker hub build. Also as I suspected, the resulting reformatting won't be too heavy since it only touches some imports.

    I also did some changes to the Makefile. I purposely removed the --verbose flag from the regular Rust build to (drum roll) reduce verbosity.

    ~Another thing I changed was the call to clippy. It now is called without any flags to prevent unwanted behavior. We should always stick to the default community standards and this helps a lot with doing so.~

    The CI will probably fail because it will be using the old docker image

    What reviewers can do

    You can check out the branch locally, run the build script (. docker/build-ubuntu), run the formatting script (. docker/run-fmt) and check whether the tests run using . docker/run-test

    opened by sphinxc0re 18
  • Enhance holochain_core_types::time::Iso8601 with DateTime conversions

    Enhance holochain_core_types::time::Iso8601 with DateTime conversions

    The Iso8601 type is currently a simple wrapper around String, with no checking. For Holofuel, we need to be able to actually operate on these as DateTime timestamps. Handling such conversions and comparisons gracefully is non-trivial.

    I have enhanced Iso8601 to maintain un-checked From traits, and have added String, in addition to static &str. This supports importation of Iso8601 data from various external sources.

    I have added checked TryFrom for &Iso8601 -> DateTime, which supports direct RFC 3339 conversion, as well as supports a greater subset of ISO 8601 timestamps, at the expense of a Regex invocation. So, you pay for what you get; quick conversion for straight, simple RFC 3339 timestamps, and support for richer ISO 8601 from external sources. Particularly, it defaults timestamps w/ no Time Zone specification to UTC, or "Zulu" time.

    This validation is done at initial Iso8601::new time, and stored for future use for fmt::Display, PartialOrd, etc. Serialization and fmt::Display always displays the canonicalized ISO 8601 form of the original timestamp (except if invalid; then the original String is produced).

    Finally, the PartialOrd and PartialEq have been implemented. Since not all Iso8601 are comparable (because they may be invalid), we treat the comparison of invalids for Equality as always false, and present None for partial_cmp (somewhat like float NaN are treated).

    opened by pjkundert 16
  • Update tarpaulin attributes

    Update tarpaulin attributes

    PR summary

    So in 0.13.4 (yanked) tarpaulin actually started passing --cfg=tarpaulin so users could do #[cfg_attr(tarpaulin, ignore)] to ignore certain tests in coverage and also conditionally include/exclude code in coverage. This had the unintended result of breaking the recommended skip attr.

    Because of that 0.13.4 was yanked and later on a 0.14.0 version released which still did --cfg=tarpaulin but also --cfg=tarpaulin_include so that code could now be skipped but still included if you did #[cfg(not(tarpaulin_include))]. There's also an unstable #[tarpaulin::skip] tool attribute for those using nightly.

    This PR changes time to use the new attributes as a user of time and tarpaulin found this broke their coverage CI.

    Link to relevant tarpaulin issue: xd009642/tarpaulin#487

    testing/benchmarking notes

    I struggled to get holochain building and running coverage on it. Still working on that but it shouldn't functionally impact any code just driving the tarpaulin source analysis and exclusion functionality.

    opened by xd009642 0
  • Fix for Async Zome Calls

    Fix for Async Zome Calls

    PR summary

    Redo PR# 2179

    testing/benchmarking notes

    ( if any manual testing or benchmarking was/should be done, add notes and/or screenshots here )

    followups

    ( any new tickets/concerns that were discovered or created during this work but aren't in scope for review here )

    changelog

    • [ ] if this is a code change that effects some consumer (e.g. zome developers) of holochain core, then it has been added to our between-release changelog with the format
    - summary of change [PR#1234](https://github.com/holochain/holochain-rust/pull/1234)

    documentation

    opened by zo-el 0
  • query_result() returns deleted entries

    query_result() returns deleted entries

    After creating and deleting an entry, query_result() will return that entry. There is no way to find out the state of the entry. I currently call get_entry() on each returned result to check if it still exists which is not very optimal. Maybe add an argument so we can specify that we don't want deleted entries?

    Code I used:

        let query_names = QueryList([entry_kind::InMail.to_owned(), entry_kind::OutMail.to_owned()].to_vec());
    let query_args = QueryArgsOptions {
        start: 0,
        limit: 0,
        headers: true,
        entries: true,
    };
    let maybe_query_result = hdk::query_result(query_names, query_args);
    bug 
    opened by ddd-mtl 0
  • Addressing version incompatibilities for patch versions

    Addressing version incompatibilities for patch versions

    Just a note to state that I'm hitting blocks in rich cross-project collaboration due to the way Holochain is managing versioning between Rust crates. There are two related issues here:

    1. SemVer is not being used to track the alpha versions
    2. Dependencies of Holochain are specified too explicitly

    (2) could be addressed in the process of solving (1) depending on the path taken.

    I have tried mitigating (1) with tilde versioning but this still does not give me means of having flexible dependencies- eg. 0.0.42-alpha5 and 0.0.47-alpha1 are considered incompatible. ~0.0 feels way too loose, and without alignment on SemVer it's unclear what this would even mean RE alpha/beta release naming.

    The end result is that every hApp codebase quickly falls into incompatibility with others, and forks / fragmentation arises to compensate. It's a very heavy maintenance & coordination burden for cross-project devs currently.

    (2) is potentially an issue, though I do note that the incompatibility I'm currently hitting with bitflags is probably unavoidable (1.0.4 → 1.2.0); however, in the case of such an unavoidable dependency update then I would expect a corresponding minor version bump in Holochain core. Would also recommend limiting such updates to security patches once we get into beta territory (I'm hoping soon!) so as to avoid unnecessary backward-incompatibility with older Holochain apps.

    opened by pospi 2
Releases(v0.0.52-alpha2)
Owner
Holochain
Scalable framework for P2P distributed apps. For all those projects you wish you could take from centralized web servers but you know can't scale on blockchain.
Holochain
GitHub
Cardano Command Line Interface (CLI) (Deprecated)

Deprecated Note: This repository implements supports for Cardano Byron, and will not be updated to works on Cardano Shelley and further. cardano-cli T

Input Output 87 Oct 9, 2022
A Rust library for working with Bitcoin SV

Rust-SV A library to build Bitcoin SV applications in Rust. Documentation Features P2P protocol messages (construction and serialization) Address enco

Brenton Gunning 51 Oct 13, 2022
Coinbase pro client for Rust

Coinbase pro client for Rust Supports SYNC/ASYNC/Websocket-feed data support Features private and public API sync and async support websocket-feed sup

null 126 Dec 30, 2022
Custom Ethereum vanity address generator made in Rust

ethaddrgen Custom Ethereum address generator Get a shiny ethereum address and stand out from the crowd! Disclaimer: Do not use the private key shown i

Jakub Hlusička 153 Dec 27, 2022
IBC modules and relayer - Formal specifications and Rust implementation

ibc-rs Rust implementation of the Inter-Blockchain Communication (IBC) protocol. This project comprises primarily four crates: The ibc crate defines t

Informal Systems 296 Jan 4, 2023
A Rust implementation of BIP-0039

bip39-rs A Rust implementation of BIP0039 Changes See the changelog file, or the Github releases for specific tags. Documentation Add bip39 to your Ca

Infincia LLC 49 Dec 9, 2022
Rust Ethereum 2.0 Client

Lighthouse: Ethereum 2.0 An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prime. Documentation Overview Lighthouse is: Read

Sigma Prime 2.1k Jan 1, 2023
Official Rust implementation of the Nimiq protocol

Nimiq Core implementation in Rust (core-rs) Rust implementation of the Nimiq Blockchain Core Nimiq is a frictionless payment protocol for the web. Thi

Nimiq 72 Sep 23, 2022
Rust implementation of Zcash protocol

The Parity Zcash client. Gitter Blog: Parity teams up with Zcash Foundation for Parity Zcash client Installing from source Installing the snap Running

Parity Technologies 183 Sep 8, 2022
rust client libraries to deal with the current cardano mainnet (byron / cardano-sl)

Rust implementation of Cardano primitives, helpers, and related applications Cardano Rust is a modular toolbox of Cardano’s cryptographic primitives,

Input Output 275 Oct 9, 2022
Tendermint in Rust!

tendermint.rs Tendermint in Rust with TLA+ specifications. Tendermint is a high-performance blockchain consensus engine for Byzantine fault tolerant a

Informal Systems 439 Jan 1, 2023
A Rust library for generating cryptocurrency wallets

Table of Contents 1. Overview 2. Build Guide 2.1 Install Rust 2.2a Build from Homebrew 2.2b Build from Crates.io 2.2c Build from Source Code 3. Usage

Aleo 554 Dec 31, 2022
Rust port of the Terry Davis' (RIP) "god says" program

RIP Terry A. Davis 1969-2018 god says Rust port of the programmer Terry Davis' "god says" (AKA GodSpeaks) program. Terrence Andrew Davis (December 15,

Orhun Parmaksız 54 Dec 26, 2022
Implementation of the Kademlia DHT protocol in Rust

kademlia-dht Simple implementation of the Kademlia DHT protocol in Rust with state dumping features for educational purposes (not production-ready). T

Leonardo Folgoni 18 Sep 24, 2022
Collection of Key Derivation Functions written in pure Rust

RustCrypto: Key Derivation Functions Collection of Key Derivation Functions (KDF) written in pure Rust. Supported Algorithms Algorithm Crate Crates.io

Rust Crypto 44 Dec 25, 2022
Cryptocurrencies trend-following trading bot sandbox written in Rust.

Trend trading bot Experiments repo about (crypto) trend trading. By "trend" I mean trading following the trend using technical indicators (vs other ki

Julien 6 Oct 2, 2022
Martinez is vNext Ethereum implementation written in pure Rust with Erigon architecture as design.

?? Martinez ?? Next-generation implementation of Ethereum protocol ("client") written in Rust, based on Erigon architecture. Why run Martinez? Look at

Arthur·Thomas 23 Jul 3, 2022
Fully typed access to the Erigon db in rust

Overview Fully typed access to the Erigon database in rust. use erigon_db::{Erigon, env_open}; use ethereum_types::Address; fn main() -> eyre::Result

Gio 89 Dec 5, 2022
The new, performant, and simplified version of Holochain on Rust (sometimes called Holochain RSM for Refactored State Model)

Holochain License: This repository contains the core Holochain libraries and binaries. This is the most recent and well maintained version of Holochai

Holochain 741 Jan 5, 2023
The new, performant, and simplified version of Holochain on Rust (sometimes called Holochain RSM for Refactored State Model)

Holochain License: This repository contains the core Holochain libraries and binaries. This is the most recent and well maintained version of Holochai

Holochain 737 Dec 28, 2022