profile
viewpoint

interledger-rs/interledger-rs 145

An easy-to-use, high-performance Interledger implementation written in Rust

ljedrz/lambda_calculus 33

A simple, zero-dependency implementation of the untyped lambda calculus in Safe Rust

koivunej/minipb 3

Reading protobuf files the hard way. This should get renamed to "Y(et) A(nother) P(roto)B(uf) (crate)".

ljedrz/blc 1

Binary lambda calculus

ljedrz/rust-misc 1

Generic stuff written in Rust

ljedrz/api 0

Promise and RxJS APIs around Polkadot and any Substrate-based chain RPC calls. It is dynamically generated based on what the Substrate runtime provides in terms of metadata. Full documentation & examples available

ljedrz/chalk 0

A PROLOG-ish interpreter written in Rust, intended eventually for use in the compiler

ljedrz/compiler-builtins 0

Porting `compiler-rt` intrinsics to Rust

ljedrz/datafrog 0

A lightweight Datalog engine in Rust

push eventljedrz/snarkOS

ljedrz

commit sha 3dbf22b958c48a2fc0e468bd2dd239018ef1bf8a

perf: pass more arguments as values in base_dpc Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

push time in 4 hours

PR opened AleoHQ/snarkOS

DPC tweaks

Builds on https://github.com/AleoHQ/snarkOS/pull/498, the last 17 commits are new.

This PR targets allocations in the snarkos-dpc crate; this is achieved with, among others:

  • removing redundant (re)allocations
  • reordering code where possible
  • using std::borrow::Cow
  • reducing the scope of allocations (allocating later, using drop on collections in some long functions)
  • reusing already-allocated vectors
  • utilizing iterators more often
  • passing arguments by value where the function requires ownership (in order to be able to consume some objects instead of cloning all references)

Posting as a draft, as there's still some possible tweaks left and I see potential for introducing some benchmarks.

+316 -328

0 comment

39 changed files

pr created time in 5 hours

push eventljedrz/snarkOS

ljedrz

commit sha 0277079af8f9081eeea1e3c92c4482ef6fe6b05c

perf: don't clone the candidate_serial_number_gadget Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 567fb8f1be2709ae7f507491632e9daa8eb107db

perf: don't allocate a Vec if padding is not needed in PedersenCommitmentGadget::check_commitment_gadget Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha c8c7abf7d6420b3f50c974e0223fc2cad95142ab

perf: reduce the scopes of Vecs in base_dpc_execute_gadget_helper Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 200fdb780cc0c36331e531a2dc5e09d26fc374a1

perf: reuse the capacity of input_bytes in base_dpc_execute_gadget_helper Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha cf36eeef9bb3fd78582f6bb7e2f264955d098ae2

refactor: change calls to Vec::truncate(v, 0) to Vec::clear(v) Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 63ac4c3e7a3a694f36a81f1c85e8b9eecec573eb

perf: allocate fewer vectors in execute_outer_proof_gadget Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 8a6eafb1e4207a470a385be825954574b872c882

perf: drop inner_snark_input_bits in execute_outer_proof_gadget as soon as it's used

view details

ljedrz

commit sha 06bbf108ad361c4c9791551db8f4c1c009c78b9a

perf: pass args by value in OuterCircuit::new Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 7a171be497a2281dac5fef8769b07873fb8d52b1

perf: pass args by value in OuterCircuit::blank Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 73aa773c1ee61a710a3dff94f50d1224536facda

perf: pass some args by value in DPCScheme::execute_online Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 5e59dc339672c95362bedff74c9f8cf1bda69bb1

perf: pass args by value in InnerCircuit::new Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha bb7344e23e269cef873963568e522f4c75298a06

refactor: remove an unnecessary double-reference Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha e6591bdff93368b24ef7bf30fadc8186365ba6e9

perf: shorten the scopes of Vecs in RecordSerializer::serialize Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 49bd6e0888206c99e638f2171537b3e74e97c722

perf: remove 2 redundant to_vec conversions Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 8f151e5d77bb32026a9c6d081e7bc6bcb957af3b

perf: don't allocate records in NoopProgram::execute Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha ba0f1ccbaf6fcb76f4fa3ed31f64bbd74f663f67

refactor: use an empty slice instead of a sliced empty Vec Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha afa0b1a1e89becf5efeeb06a61d83184c0e4a46c

perf: pass more arguments as values in base_dpc Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

push time in 5 hours

create barnchljedrz/snarkOS

branch : dpc_tweaks_copy

created branch time in 5 hours

push eventljedrz/snarkOS

ljedrz

commit sha feb1f37918145c86e2a7e4fe8f28d176a019f6ff

perf: reduce allocations in push_namespace Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

push time in 11 hours

pull request commentAleoHQ/snarkOS

Clippy compliance 1.47

Rebased.

ljedrz

comment created time in 12 hours

push eventljedrz/snarkOS

dependabot-preview[bot]

commit sha e1fae26e551ea5e0297ff2395a8fe2e59cb90f66

build(deps): bump base64 from 0.12.3 to 0.13.0 Bumps [base64](https://github.com/marshallpierce/rust-base64) from 0.12.3 to 0.13.0. - [Release notes](https://github.com/marshallpierce/rust-base64/releases) - [Changelog](https://github.com/marshallpierce/rust-base64/blob/master/RELEASE-NOTES.md) - [Commits](https://github.com/marshallpierce/rust-base64/compare/v0.12.3...v0.13.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

ljedrz

commit sha 871ccf0d8918d61be0a43a04bd4ad22cf849c78b

perf: don't allocate a c_query_1 Vec in gm17::generate_parameters Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha d5e96b58ed4e9d1bf66f818acf4282870c8d23a8

perf: don't collect() if not needed Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 0f47133c3ebd2f99733865d00aac64962572f2cb

perf: don't use to_vec() if not needed Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 6bfc85752bf7a0e3ec546d6bc0dd8a7cdf40a9bc

perf: pass items as values in GroupGadget::mul_bits Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 712efb595037914da7b2653c99c14cbb14cc25f7

perf(drive-by): don't clone() for the purposes of to_bits_le Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 6169b76bbd242273599abef902fd5ed6b755917d

perf: use into_iter() instead of iter().cloned() where possible Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 4e412b94d5c2b32f36da25c1744ca2762f858f77

perf: make PairingEngine::{miller_loop, product_of_pairings} work on values Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

dependabot-preview[bot]

commit sha e3d761db24167e71804bd42b1cf75227fdc51090

build(deps): bump thiserror from 1.0.20 to 1.0.21 Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.20 to 1.0.21. - [Release notes](https://github.com/dtolnay/thiserror/releases) - [Commits](https://github.com/dtolnay/thiserror/compare/1.0.20...1.0.21) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

dependabot-preview[bot]

commit sha fc9badcfa9d5d12c490f2b7aba77febe59df1f6f

build(deps): bump rayon from 1.4.0 to 1.5.0 Bumps [rayon](https://github.com/rayon-rs/rayon) from 1.4.0 to 1.5.0. - [Release notes](https://github.com/rayon-rs/rayon/releases) - [Changelog](https://github.com/rayon-rs/rayon/blob/master/RELEASES.md) - [Commits](https://github.com/rayon-rs/rayon/compare/rayon-core-v1.4.0...rayon-core-v1.5.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

dependabot-preview[bot]

commit sha 99d998c00415aadfb55b9dbf1ba193d02d1f4d9f

build(deps): bump serde_json from 1.0.57 to 1.0.59 Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.57 to 1.0.59. - [Release notes](https://github.com/serde-rs/json/releases) - [Commits](https://github.com/serde-rs/json/compare/v1.0.57...v1.0.59) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

dependabot-preview[bot]

commit sha 865f6666f437ce56ea06be0c609d38924524baa3

build(deps): bump chrono from 0.4.15 to 0.4.19 Bumps [chrono](https://github.com/chronotope/chrono) from 0.4.15 to 0.4.19. - [Release notes](https://github.com/chronotope/chrono/releases) - [Changelog](https://github.com/chronotope/chrono/blob/main/CHANGELOG.md) - [Commits](https://github.com/chronotope/chrono/compare/v0.4.15...v0.4.19) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

Howard Wu

commit sha 0cff124effcf02f5b426857e426e7f78b24faed9

Merge branch 'master' into memory_tweaks3

view details

ljedrz

commit sha 5be1934ff7943201f20fe681f756360395e19731

perf: break DenseOrSparsePolynomial::iter_with_index into non-allocating inline iteration Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 60738a4c01b5b6b1673297e4ed02d38c8ab8cd7f

perf: make RecordPayload::to_bytes return a slice instead of a Vec Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha fa11958ce47002ca1395f74fd05d8ed92a37d485

perf: speed up UInt::to_bits_le Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 5659c65177294f0751fd030b5d85e28f8b642469

perf: make MarlinKZG10::normalize_commitments not allocate the result Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha db16595aa5d35468fa868b9126035321a18ec388

perf: don't allocate LabeledCommitment vectors where avoidable Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha d5390c2223134bc67c8e77ef7fdc1b525f66c20d

perf: don't allocate using bytes_to_bits where possible Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha ade796ce2c6c464267efaca610af584b7b94cc04

perf: don't allocate in bits_to_bytes in case of no padding Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

push time in 12 hours

PR opened AleoHQ/snarkOS

Speed up TestConstraintSystem's set_named_obj

This change reduces the number of BTreeMap lookups by 1 in every call to the (very popular) ns method, improving the results of non-const benchmarks introduced in https://github.com/AleoHQ/snarkOS/pull/501 by 15-20%.

+9 -5

0 comment

1 changed file

pr created time in 3 days

create barnchljedrz/snarkOS

branch : speed_up_ns

created branch time in 3 days

push eventljedrz/snarkOS

ljedrz

commit sha 0091eeba685b76eaea6f1d9471226525350bf7f6

bench: introduce integer arithmetic benchmarks Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

push time in 3 days

push eventljedrz/snarkOS

ljedrz

commit sha 02356507ed40daa1d9e10a6f0b25619051ce8f1f

fixup

view details

push time in 3 days

create barnchljedrz/snarkOS

branch : condselect_cow

created branch time in 3 days

PR opened AleoHQ/snarkOS

Introduce integer arithmetic benchmarks

This PR adds a range of integer arithmetic benchmarks that will aid future performance improvement efforts. They were based on existing tests and use macros to reduce code duplication. The operations included are:

  • addmany
  • sub
  • mul
  • div
  • pow and their counterparts on constant numbers.
+519 -0

0 comment

3 changed files

pr created time in 3 days

create barnchljedrz/snarkOS

branch : arithmetic_benches

created branch time in 3 days

pull request commentAleoHQ/snarkOS

Pass Circuit by reference

Rebased.

ljedrz

comment created time in 4 days

push eventljedrz/snarkOS

raychu86

commit sha e8cfb1685e0a911060b2ac84a409ce61aa8a49f5

Fix import in benchmarks

view details

Howard Wu

commit sha 66978913dc15e151722dc48d568c82781edb5f08

Merge pull request #474 from AleoHQ/fix/benchmark-compilation Hotfix: Fix import in benchmarks

view details

ljedrz

commit sha 1050f7393ce630fc05327ffaa9ee64ad287d4c14

logs: replace the log dep with tracing (including log feature) Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 7db294b47b6b53d0bebf8975ff72cf136f48610a

logs: use tracing-subscriber instead of env-logger Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 5b60ec60f7951b84b10ce749bdb68913bbe76081

logs: enable rudimentary node tracing Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha baafe483daf9668796930b9b2f5bc5a35fad7b47

logs: more specific tracing for the tasks spawned for dedicated purposes Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 10c3be7eb8273167bc782d3e72cdabdd7b1e202d

fix: make cargo bench operational Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 57f4de3befbcb3661ae3c41e5baf4bcf64ae9dda

feat: use criterion to benchmark curves Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

Howard Wu

commit sha 87f531559a48c41a79cf3ef4dc118acbfce0a68c

Merge pull request #473 from ljedrz/clippy_compliance1 Clippy compliance, part 1

view details

Howard Wu

commit sha e448291edca510b4cd8f989787127bf22f4641e6

Merge pull request #477 from ljedrz/clippy_compliance2 Clippy compliance, part 2

view details

Howard Wu

commit sha c9e5f823b8493f8c3a6c43e6f4dfd16173b99957

Merge pull request #481 from ljedrz/benchmark_fix Make cargo bench operational

view details

ljedrz

commit sha 24b8bb507c0358a5dfb6aa966093f583ca5b8e9a

perf: pre-allocate the expected capacity for Vecs where possible Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha c35828209ec4615d9cbc1ffb3a7135eb591cbf7f

perf: use dedicated Iterator methods instead of Vec pushing Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 37b0a0411ac50a97d3dde4e8ff36c19d0972f3f8

refactor: derive Default for more objects Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 7b6def2b09fe31e97c0ae7b4165f45998776aaaa

perf: pre-allocate the RecordSerializer vectors Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 199b6ac8dc7c8bdab074fa3404670f40a03421d2

perf: optimize MessageHeader::serialize Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

Howard Wu

commit sha 1a43baf1dba54f5bae7441a82b5cb5580f52b901

Merge pull request #478 from ljedrz/clippy_compliance3 Clippy compliance, part 3 (final)

view details

Howard Wu

commit sha 9a31273deb4b1c2f317b651dc2a0b39b9873b8ee

Merge pull request #480 from ljedrz/log_to_tracing Change the logging setup from log to tracing

view details

Howard Wu

commit sha 0c3cb38a4eb6358b44138510f7b1d5862e2d018c

Merge pull request #483 from ljedrz/more_criterion Use criterion in curve benchmarks

view details

Howard Wu

commit sha 72d69844603e7fbcae41bd94a1c9c2bbb78f366c

Update dpc/src/base_dpc/record/record_serializer.rs

view details

push time in 4 days

pull request commentAleoHQ/snarkOS

Clippy compliance 1.47

Rebased.

ljedrz

comment created time in 4 days

push eventljedrz/snarkOS

ljedrz

commit sha ec4a16bc0c95db4d40f1d2dcf9651643cb3710cd

clippy: handle --workspace issues Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 186bcba3de282d9047dfbc30322a029d2239d7d4

clippy: handle --workspace --examples issues Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 950a2bcf9841acd5807cd71e8f87aa20b022d499

clippy: deduplicate a closure into a free function in Boolean tests Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 92d4a153d158aa396b7422b2ecf7195dae45a112

clippy: handle most --workspace --tests issues Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 13a1d31e297bd6abd3a5c6335a57bdc5e2e1097d

clippy: fix the eval_order_dependence test issues Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 1050f7393ce630fc05327ffaa9ee64ad287d4c14

logs: replace the log dep with tracing (including log feature) Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 7db294b47b6b53d0bebf8975ff72cf136f48610a

logs: use tracing-subscriber instead of env-logger Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 5b60ec60f7951b84b10ce749bdb68913bbe76081

logs: enable rudimentary node tracing Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha baafe483daf9668796930b9b2f5bc5a35fad7b47

logs: more specific tracing for the tasks spawned for dedicated purposes Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 57f4de3befbcb3661ae3c41e5baf4bcf64ae9dda

feat: use criterion to benchmark curves Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 24b8bb507c0358a5dfb6aa966093f583ca5b8e9a

perf: pre-allocate the expected capacity for Vecs where possible Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha c35828209ec4615d9cbc1ffb3a7135eb591cbf7f

perf: use dedicated Iterator methods instead of Vec pushing Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 37b0a0411ac50a97d3dde4e8ff36c19d0972f3f8

refactor: derive Default for more objects Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 7b6def2b09fe31e97c0ae7b4165f45998776aaaa

perf: pre-allocate the RecordSerializer vectors Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 199b6ac8dc7c8bdab074fa3404670f40a03421d2

perf: optimize MessageHeader::serialize Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

Howard Wu

commit sha 1a43baf1dba54f5bae7441a82b5cb5580f52b901

Merge pull request #478 from ljedrz/clippy_compliance3 Clippy compliance, part 3 (final)

view details

Howard Wu

commit sha 9a31273deb4b1c2f317b651dc2a0b39b9873b8ee

Merge pull request #480 from ljedrz/log_to_tracing Change the logging setup from log to tracing

view details

Howard Wu

commit sha 0c3cb38a4eb6358b44138510f7b1d5862e2d018c

Merge pull request #483 from ljedrz/more_criterion Use criterion in curve benchmarks

view details

Howard Wu

commit sha 72d69844603e7fbcae41bd94a1c9c2bbb78f366c

Update dpc/src/base_dpc/record/record_serializer.rs

view details

Howard Wu

commit sha b13e295abd8385f8751aabfaf8aa170c6e94af8e

Merge pull request #492 from ljedrz/memory_tweaks More vector pre-allocations

view details

push time in 4 days

push eventljedrz/snarkOS

ljedrz

commit sha 5be1934ff7943201f20fe681f756360395e19731

perf: break DenseOrSparsePolynomial::iter_with_index into non-allocating inline iteration Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 60738a4c01b5b6b1673297e4ed02d38c8ab8cd7f

perf: make RecordPayload::to_bytes return a slice instead of a Vec Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha fa11958ce47002ca1395f74fd05d8ed92a37d485

perf: speed up UInt::to_bits_le Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 5659c65177294f0751fd030b5d85e28f8b642469

perf: make MarlinKZG10::normalize_commitments not allocate the result Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha db16595aa5d35468fa868b9126035321a18ec388

perf: don't allocate LabeledCommitment vectors where avoidable Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha d5390c2223134bc67c8e77ef7fdc1b525f66c20d

perf: don't allocate using bytes_to_bits where possible Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha ade796ce2c6c464267efaca610af584b7b94cc04

perf: don't allocate in bits_to_bytes in case of no padding Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 4ad425a6648582cead033e36457850300fc39542

perf: fewer allocations in variable_length_integer Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 14f3ed55b227c971290021a7a1587cea65a4582c

fix: small post-merge refactoring Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

push time in 4 days

delete branch ljedrz/snarkOS

delete branch : log_to_tracing

delete time in 4 days

delete branch ljedrz/snarkOS

delete branch : memory_tweaks

delete time in 4 days

delete branch ljedrz/snarkOS

delete branch : more_criterion

delete time in 4 days

delete branch ljedrz/snarkOS

delete branch : clippy_compliance3

delete time in 4 days

delete branch ljedrz/interledger-rs

delete branch : partially_fix_615

delete time in 4 days

delete branch ljedrz/interledger-rs

delete branch : drive_bys

delete time in 4 days

push eventljedrz/leo

ljedrz

commit sha 09d456c01ed3e69b34f115e07c12c082c891dfea

bench: introduce integer arithmetic benchmarks Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 1e25738890602c8dad3ff5f9860d30b4f94763c6

refactor: minor tweaks for signed_integer::div Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 55d0f2e340f73eb2bd8cc35f513133d5774f3a51

perf: reduce allocations in the Neg impl for Vec<Boolean> Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 63f80c0472c2f1449bbbcd0166b6ccd2e538f4a4

perf: reduce allocations in AllocGadget::{alloc, alloc_input} Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 4ccc9c31db9f1c47c460d7569e21810ff98f68e5

perf: reduce format!-related allocations and move them to closures where possible Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha f9e6b3caa860e0d4c79eff8f6db609ccaf5423c0

perf: a small optimization to signed_integer equality checks Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 78f98f1f26cab36cf5a7fc4e93c0777311defbbf

perf: reduce allocations in signed_integer's CondSelectGadget impl Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 710bbc673007f3769cf3c2f5b1b85d3197c16e23

perf: reduce allocations in Boolean's SignExtend impl Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

push time in 4 days

push eventljedrz/leo

dependabot-preview[bot]

commit sha eeb97fa390c3e4dd73d55e7cbfcdea83d4cd851d

Bump thiserror from 1.0.20 to 1.0.21 Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.20 to 1.0.21. - [Release notes](https://github.com/dtolnay/thiserror/releases) - [Commits](https://github.com/dtolnay/thiserror/compare/1.0.20...1.0.21) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

dependabot-preview[bot]

commit sha de793b5356c7553d91a38cf00a1a582b4c2c9de0

Bump tracing-subscriber from 0.2.12 to 0.2.13 Bumps [tracing-subscriber](https://github.com/tokio-rs/tracing) from 0.2.12 to 0.2.13. - [Release notes](https://github.com/tokio-rs/tracing/releases) - [Commits](https://github.com/tokio-rs/tracing/compare/tracing-subscriber-0.2.12...tracing-subscriber-0.2.13) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

dependabot-preview[bot]

commit sha eb17a1d489481a231250289a59f69bd1632864a7

Bump toml from 0.5.6 to 0.5.7 Bumps [toml](https://github.com/alexcrichton/toml-rs) from 0.5.6 to 0.5.7. - [Release notes](https://github.com/alexcrichton/toml-rs/releases) - [Commits](https://github.com/alexcrichton/toml-rs/compare/0.5.6...0.5.7) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

dependabot-preview[bot]

commit sha c8ccdb9c61c31425a45b8c58d5138139fd269e6e

Bump serde_json from 1.0.57 to 1.0.59 Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.57 to 1.0.59. - [Release notes](https://github.com/serde-rs/json/releases) - [Commits](https://github.com/serde-rs/json/compare/v1.0.57...v1.0.59) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

dependabot-preview[bot]

commit sha 56f6edd2c24826a2e1b3a1f51948cfcc2c2c4282

Bump console from 0.12.0 to 0.13.0 Bumps [console](https://github.com/mitsuhiko/console) from 0.12.0 to 0.13.0. - [Release notes](https://github.com/mitsuhiko/console/releases) - [Changelog](https://github.com/mitsuhiko/console/blob/master/CHANGELOG.md) - [Commits](https://github.com/mitsuhiko/console/compare/v0.12.0...v0.13.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

dependabot-preview[bot]

commit sha 2afa4d518889998a084dc1936cbecc5043451240

Bump env_logger from 0.7.1 to 0.8.1 Bumps [env_logger](https://github.com/env-logger-rs/env_logger) from 0.7.1 to 0.8.1. - [Release notes](https://github.com/env-logger-rs/env_logger/releases) - [Changelog](https://github.com/env-logger-rs/env_logger/blob/master/CHANGELOG.md) - [Commits](https://github.com/env-logger-rs/env_logger/compare/v0.7.1...v0.8.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

ljedrz

commit sha 115b7f226691ce9bf9d7d55e1ad8aacb7086723d

test: fix a few CI warnings Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

Collin Chin

commit sha 899c884da56271e0050af727c9a57f48fa27eb20

Merge pull request #386 from AleoHQ/dependabot/cargo/thiserror-1.0.21 Bump thiserror from 1.0.20 to 1.0.21

view details

Collin Chin

commit sha 0cf9c1511682bca5d37d371d6d86b7f84aba7045

Merge pull request #387 from AleoHQ/dependabot/cargo/tracing-subscriber-0.2.13 Bump tracing-subscriber from 0.2.12 to 0.2.13

view details

Collin Chin

commit sha 3d021c4c4a02f61f96f4f5a0f004ab6ca48115a6

Merge pull request #389 from AleoHQ/dependabot/cargo/toml-0.5.7 Bump toml from 0.5.6 to 0.5.7

view details

Collin Chin

commit sha bd857d555b5c000f3c8e3b190748d13f480d1ea9

Merge pull request #390 from AleoHQ/dependabot/cargo/serde_json-1.0.59 Bump serde_json from 1.0.57 to 1.0.59

view details

dependabot-preview[bot]

commit sha 2b1894c88b047ca5a3ebf13c3663bc4427d098c9

Bump serde from 1.0.116 to 1.0.117 Bumps [serde](https://github.com/serde-rs/serde) from 1.0.116 to 1.0.117. - [Release notes](https://github.com/serde-rs/serde/releases) - [Commits](https://github.com/serde-rs/serde/compare/v1.0.116...v1.0.117) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

Collin Chin

commit sha 8f9e195ed68c199bf302cbe48a36da6ccd63d6d0

Merge pull request #395 from AleoHQ/dependabot/cargo/serde-1.0.117 Bump serde from 1.0.116 to 1.0.117

view details

Collin Chin

commit sha b190752a3c4f74b53431addd99e81fbc9b61d200

Merge pull request #397 from AleoHQ/dependabot/cargo/console-0.13.0 Bump console from 0.12.0 to 0.13.0

view details

Collin Chin

commit sha 36c6c976f2d33095531934c613a958d0d417fb48

Merge pull request #398 from AleoHQ/dependabot/cargo/env_logger-0.8.1 Bump env_logger from 0.7.1 to 0.8.1

view details

Collin Chin

commit sha f62d2d7930f2bd9e059d5c0b84a510da6ec662f1

Merge pull request #402 from ljedrz/post_merge_cleanup A few post-merge cleanups

view details

ljedrz

commit sha d98ae0a105e2203132b2ac0fb168c6f6650e5121

refactor: pass Span by value in set_span methods Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 153202752f6a65bcc36ea1a3c60ee5cafa191c42

refactor: use matches! in Type methods Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha afe669babd89ec919fb013bd30e8da583e79c837

perf: make signed_integer's is_constant method faster Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha e5f47b8254e4e1781c64f1ff4695ceec8d67b0ca

perf: make Address is_constant method faster Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

push time in 4 days

delete branch ljedrz/leo

delete branch : post_merge_cleanup

delete time in 5 days

create barnchrs-ipfs/substrate

branch : offchain_ipfs

created branch time in 5 days

push eventljedrz/leo

ljedrz

commit sha 115b7f226691ce9bf9d7d55e1ad8aacb7086723d

test: fix a few CI warnings Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

push time in 5 days

push eventrs-ipfs/substrate

Benjamin Kampmann

commit sha cb833913c4308b6342474d3ec16e4e34ddf43670

Remove pallet-balances from non-dev-deps (#6407)

view details

Rakan Alhneiti

commit sha 9b08492e1e7d9a939c0cd9de19059be0b42c4deb

Babe VRF Signing in keystore (#6225) * Introduce trait * Implement VRFSigner in keystore * Use vrf_sign from keystore * Convert output to VRFInOut * Simplify conversion * vrf_sign secondary slot using keystore * Fix RPC call to claim_slot * Use Public instead of Pair * Check primary threshold in signer * Fix interface to return error * Move vrf_sign to BareCryptoStore * Fix authorship_works test * Fix BABE logic leaks * Acquire a read lock once * Also fix RPC acquiring the read lock once * Implement a generic way to construct VRF Transcript * Use make_transcript_data to call sr25519_vrf_sign * Make sure VRFTranscriptData is serializable * Cleanup * Move VRF to it's own module * Implement & test VRF signing in testing module * Remove leftover * Fix feature requirements * Revert removing vec macro * Drop keystore pointer to prevent deadlock * Nitpicks * Add test to make sure make_transcript works * Fix mismatch in VRF transcript * Add a test to verify transcripts match in babe * Return VRFOutput and VRFProof from keystore

view details

Toralf Wittner

commit sha caf9fbe005b6fd4505e824ad969e379b89e72d52

Update `libp2p-ping`. (#6412) Bugfix release, see [CHANGELOG]. [CHANGELOG]: https://github.com/libp2p/rust-libp2p/blob/master/protocols/ping/CHANGELOG.md

view details

Pierre Krieger

commit sha 7a4bd762e0e8c2ddf959787981cd2e55d080b47d

Remove --legacy-network-protocol CLI flag (#6411)

view details

Gavin Wood

commit sha 4f0b60164855339cc645ceeba3c554c5cc5cf59f

Scale and increase validator count (#6417)

view details

Shawn Tabrizi

commit sha 369f9fc2f5493a94398e8ce132832b9dc4752af4

Expose constants from Proxy Pallet (#6420)

view details

Max Inden

commit sha 31c3e06ded197bdf28130ac0c5310283b2d1b5b3

.maintain/monitoring: Add alerting rule tests (#6343) * .maintain/monitoring: Add alerting rule tests * .maintain/monitoring/alerting-rules/alerting-rules.yaml: Break lines * .gitlab-ci.yml: Add promtool rule testing step

view details

s3krit

commit sha 31af20346a0f0c47bf776f029e6579acd473b2d3

[CI] Label PRs if polkadot companion build fails (#6410) * add polkadot-companion-labels.yml * fix polkadot companion job name * add opened event to polkadot-companion-labels.yml * Dont label on timeouts * increase timeouts * increase timeouts again... to be sure * Switch to s3krit/await-status-action Turns out Sibz/await-status-action looks at /ref/statuses, which lists ALL statuses (i.e., if you send a pending and a failure for the same context, it will see both and assume the job is still pending.). I forked and point at /ref/status, which shows a combined summary of each status (i.e., only ever shows the most recent status of a single context).

view details

Bastian Köcher

commit sha 3ca1d91f0f53f03d95e5335ad3d7d125e379c9d6

Print bad mandatory error (#6416) * Print bad mandatory error This prints the error that leads to bad mandatory. * Update frame/system/src/lib.rs Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com> * Adds missing trait import Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>

view details

Bastian Köcher

commit sha 97583766efde5eb628ebda73add493aa3f87d8e7

Track last blocks in informant display (#6429) This implements tracking of the last seen blocks in informant display to prevent printing the import message twice. In Cumulus we first import blocks as part of the block building with `new_best == false` and set the best block after we know which one was included by the relay chain. This leads to printing the import messages two times. This pr solves the problem by track the latest seen blocks to not print the message twice.

view details

Dan Forbes

commit sha 2bb79cb6500d0bc338ca4c480c66ced0d284b0a4

Simple Docs for Atomic Swap Pallet (#6434) * Simple Docs for Atomic Swap Pallet * Fix copy-and-paste error

view details

Cecile Tonglet

commit sha a2c493d4de8e5f0a3c8bf9b0518b45aa35b2cb71

More descriptive error message when invalid slot duration is used (#6430) * Initial commit Forked at: d735e4d0b5378c227f81a5127a1d4544de112fd8 No parent branch. * Errors if slot_duration is zero * Errors if slot_duration is zero * Revert "Errors if slot_duration is zero" This reverts commit a9e9820e124571f73d3e498e969a74d01fd3fe96. * Update client/consensus/slots/src/lib.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>

view details

Guillaume Thiolliere

commit sha d343bfc87acf1eb5cbff49827eea2d59b729724b

Root origin use no filter by default. Scheduler and Democracy dispatch without asserting BaseCallFilter (#6408) * make system root origin build runtime origin with no filter * additional doc

view details

Guillaume Thiolliere

commit sha 111b628ccd2895dce26f2af12ee5f28206fa9e2b

llow decl-module to have a where clause with trailing comma (#6431)

view details

Max Inden

commit sha 18707b3314bc2c48991ca68a53539fc98b9a092d

.gitlab-ci.yml: Use promtool from paritytech/tools:latest image (#6425)

view details

Bastian Köcher

commit sha 26aec420371a41f7202bb50a98dac4b0fcce591e

Update sync chain info on own block import (#6424) Before we only updated the chain info of sync when we have imported something using the import queue. However, if you import your own blocks, this is not done using the import queue and so sync is not updated. If we don't do this, it can lead to sync switching to "major sync" mode because sync is not informed about new blocks. This especially happens on Cumulus, where a collator is selected multiple times to include its block into the relay chain and thus, sync switches to major sync mode while the node is still building blocks.

view details

Max Inden

commit sha 4c67aeec54bfa255eed88d391e2f401434d1e51f

client/authority-discovery: Compare PeerIds and not Multihashes (#6414) In order to tell whether an address is the local nodes address the authority discovery module previously compared the Multihash within the `p2p` Multiaddr protocol. rust-libp2p recently switched to a new PeerId representation (see [1]). Multihashes of the same PeerId in the new and the old format don't equal. Instead of comparing the Multihashes, this patch ensures the module compares the PeerIds [1] https://github.com/libp2p/rust-libp2p/issues/555

view details

Nikolay Volf

commit sha c8c16d1803c5d84565ffb788ab35e2cedf289530

add network propagated metrics (#6438)

view details

Denis Pisarev

commit sha f9d4d302e797e82aecf9782c4af8dc6abc4074a0

change (ci): add interruptible to kubernetes jobs (#6441)

view details

Gavin Wood

commit sha 9cbda1eab93a1384086b4b88b6995669ed6435d2

Avoid multisig reentrancy (#6445)

view details

push time in 5 days

push eventrs-ipfs/substrate

Ashley

commit sha 65cc9af9b8df8d36928f6144ee7474cefbd70454

Add missing fields to the light sync state (#7225) * Initial draft * Add an iterator that helps us get most items * Revert changes to grandpa * Change fields to just be the grandpa authority set and babe epoch changes * Only use the fields we need from the shared authority set * Switch to RPC call * Revert "Only use the fields we need from the shared authority set" This reverts commit a8f0966794e01fb70ca67b990bce23bccb500525. * Add babe_finalized_block_weight from `ashley-improve-sync-state-WIP-loading` * Fix rpc test * Move sync state rpc stuff into sc-sync-state-rpc * Remove as_json_value and remove unwraps from sc-sync-state-rpc * Add clone_inner to SharedAuthoritySet

view details

Aten

commit sha 45402941d7d20090049442fcfa401b80e6c04e81

Update token info about ChainX. (#7330)

view details

André Silva

commit sha cefcd99d5156bfe3476124f356cd54083a43a49d

frame: remove finality-tracker (#7228) * frame: remove finality-tracker * node: remove unused parameter types * node: bump spec_version

view details

André Silva

commit sha bb79f651b0e4f3f6bf1d12f8e1af4724c8836708

sync: only restart peers not doing finality related requests (#7322) * sync: only restart peers not doing finality related requests * sync: add test for sync restart * sync: add better docs to restart method

view details

Pierre Krieger

commit sha ec1834646c3f81305dd01cc85d003d7be76daebf

No longer actively open legacy substreams (#7076) * Allow remotes to not open a legacy substream * No longer actively open legacy substreams * Misc fixes * Line width * Special case first protocol as the one bearing the handshake * Legacy opening state no longer keeps connection alive * Remove now-unused code * Simplify inject_dial_upgrade_error * [chaos:basic] * [chaos:basic] * [chaos:basic]

view details

André Silva

commit sha 375adf87b613add6412e0718f21c7c93f17336d5

consensus: prioritize finality work over block import in queue (#7307) * consensus: prioritize finality work over block import in queue * consensus: add test for import queue task priority

view details

s3krit

commit sha 2174c50cfc0703f7794d840cd643a1444b2cdb85

remove github release action (#7338)

view details

Bastian Köcher

commit sha b936fa86becf4601b5ca81fd7265488a2a026860

Adds support for inspecting a hex encoded public key (#7344) * Adds support for inspecting a hex encoded public key This adds support for inspecting hex encoded public keys to subkey. The command looks like: `subkey inspect --public 0xPUBLICHEX` * Update client/cli/src/commands/utils.rs Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com> Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>

view details

Shawn Tabrizi

commit sha 900d034fc1ba0ccb30dd54b2dd7498ad5caa7fb5

Constant Weight Signature in Benchmarking CLI (#7233) * Don't remove unused components * add more metadata to generated file * unused code * proposed format * Revert "proposed format" This reverts commit ce522c3480157ab6670bcbd9b17e1398168cabf4. * Update weight signatures and unused components in benchmarks * Keep timestamp constant time * remove component from as_derivative

view details

Bastian Köcher

commit sha 6fdf3db007b3069f507cb6530c0c042e42c511d4

Make `queryStorage` and `storagePairs` unsafe RPC functions (#7342) The RPC calls can be rather expensive and can easily bring a RPC node in some problems ;)

view details

Bastian Köcher

commit sha c2469ebdfbb9d051f892c7b896e835d78d60838d

Move `IsSubType` and write some docs for the trait (#7350) * Move `IsSubType` and write some docs for the trait This moves the `IsSubType` trait from dispatch.rs to traits.rs. It also adds docs to make the trait better understandable. * Update frame/support/src/traits.rs Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com> Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>

view details

Guillaume Thiolliere

commit sha fb45308f3e61f49c36ff8a0186ff204fcdf5ea13

Derive no bound macros (to be also used in pallet macro) (#7280) * derive no bound macros * explicit different variant for partialeq * fix ui for 1.47 * Apply suggestions from code review Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * move test to frame-support-test * renames, code organization and remove expect as suggested * better doc * remove DebugStripped introduce RuntimeDebugNoBound * rename * fix test * fix ui test * fix line width * Update frame/support/src/lib.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Update frame/support/procedural/src/clone_no_bound.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * fix confusing dead code Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>

view details

Bastian Köcher

commit sha a3e8ca18fbdb5a33e3d1bbfcfcff03b7398fc5a5

Make `wasm-builder` print the rustc version (#7351) * Make `wasm-builder` print the rustc version This makes `wasm-builder` print the rustc version that is being used to compile the project. This is rather useful, because people can check faster if the used rustc version is maybe known for being broken with Substrate. * Apply suggestions from code review * Add some comments

view details

André Silva

commit sha 56205634082f7f64ae2eb1f09a57d79d04dc8597

grandpa: remove duplicate function to fetch local authority id (#7359) * grandpa: remove duplicate authority_id function * grandpa: rename is_voter to local_authority_id * grandpa: cleanup rebuild_voter telemetry event

view details

Max Inden

commit sha b49b666043c61891faa3b56ce7fc4d74c40ebad8

client/network: Remove option to disable yamux flow control (#7358) With the `OnRead` flow control option yamux "send[s] window updates only when data is read on the receiving end" and not as soon as "a Stream's receive window drops to 0". Yamux flow control has proven itself. This commit removes the feature flag. Yamux flow control is now always enabled.

view details

Max Inden

commit sha 15247034e467c89fa6bef3d8a8b25a0f3a754c51

*: Bump async-std to v1.6.5 (#7306) * *: Bump async-std to v1.6.5 Prevent users from using v1.6.4 which faces issues receiving incoming TCP connections. See https://github.com/async-rs/async-std/issues/888 for details. * client/network/src/gossip: Use channel instead of condvar `async_std::sync::Condvar::wait_timeout` uses `gloo_timers::callback::Timeout` when compiled for `wasm32-unknown-unknown`. This timeout implementation does not fulfill the requirement of being `Send`. Instead of using a `Condvar` use a `futures::channel::mpsc` to signal progress from the `QueuedSender` to the background `Future`. * client/network/Cargo.toml: Remove async-std unstable feature * client/network/src/gossip: Forward all queued messages * client/network/gossip: Have QueuedSender methods take &mut self * client/network/gossip: Move queue_size_limit into QueuedSender The `queue_size_limit` field is only accessed by `QueuedSender`, thus there is no need to share it between the background future and the `QueuedSender`. * client/network/gossip: Rename background task to future To be a bit picky the background task is not a task in the sense of an asynchonous task, but rather a background future in the sense of `futures::future::Future`.

view details

Bastian Köcher

commit sha 743981a083f244a090b40ccfb5ce902199b55334

Fix logging from inside the WASM runtime (#7355) * Fix logging from inside the WASM runtime When using `RuntimeLogger` to log something from the runtime, we didn't set any logging level. So, we actually did not log anything from the runtime as logging is disabled by default. This pr fixes that by setting the logging level to `TRACE`. It also adds a test to ensure this does not break again ;) * Update frame/support/src/debug.rs

view details

Nikolay Volf

commit sha 184527825c0f9c2037df99406fec029d3cfbba12

Runtime worker threads (#7089) * std variant * principal work * format and naming * format and naming continued * working nested fork * add comment * naming and tabs * line width * fix wording * address review * refactor dynamic dispatch * update wasmtime * some care * move ext * more refactor * doc effort * simplify * doc effort * tests and docs * address review * naming * explain some args * add example * unwinding for native and tests * rename stray * fix refs * fix tests * fix warnings * stray naming * fixes and comments * Update primitives/io/src/tasks.rs Co-authored-by: cheme <emericchevalier.pro@gmail.com> * make examples "compile" * dyn_dispatch -> spawn_call * fix impl * address review * Update primitives/io/src/lib.rs Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> * Update primitives/io/src/tasks.rs Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> * Update primitives/io/src/async_externalities.rs Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> * Update primitives/io/src/tasks.rs Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> * Update frame/example-parallel/src/lib.rs Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> * fix compilation * Update client/executor/common/src/wasm_runtime.rs Co-authored-by: Sergei Shulepov <sergei@parity.io> * address review * Update client/executor/wasmtime/src/instance_wrapper.rs Co-authored-by: Sergei Shulepov <sergei@parity.io> * Update client/executor/src/native_executor.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Update primitives/io/src/tasks.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Update client/executor/src/native_executor.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Update primitives/io/src/tasks.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Update client/executor/wasmtime/src/instance_wrapper.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * address some issues * address more issues * wasm_only interface * define sp_tasks * avoid anyhow * fix example Co-authored-by: cheme <emericchevalier.pro@gmail.com> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Sergei Shulepov <sergei@parity.io> Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>

view details

Max Inden

commit sha 5cad89412b4877486baedccb46615de05e39d53c

client/network: Allow configuring Kademlia's disjoint query paths (#7356) The Rust libp2p-kad implementation can require iterative queries to use disjoint paths for increased resiliency in the presence of potentially adversarial nodes. Allow Substrate users to enable this feature via the `--kademlia-disjoint-query-paths` flag.

view details

Cecile Tonglet

commit sha a4673586a469a1a2c6e17ab9dea048a1307cb9cf

Add node name to the log lines (#7328) * Initial commit Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * WIP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * WIP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * WIP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * WIP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * WIP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * CLEANUP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * Add notes to original source code * CLEANUP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * CLEANUP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * WIP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * WIP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * WIP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * CLEANUP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * WIP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * Some doc * Test with trybuild * Revert "Test with trybuild" (issue with trybuild atm) This reverts commit 9055ec2206808ba3ddce6e3d87eb358907fa5e42. https://github.com/dtolnay/trybuild/issues/53 * Apply suggestions * Rename derive to proc-macro * Remove "prefix" feature from informant * Blocking task should use SpawnHandle::spawn_blocking * Improve doc as suggested * Fixes Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * Apply suggestion * Update client/cli/proc-macro/src/lib.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * More suggestions * CLEANUP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * Improve error message * CLEANUP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * Fix async issue * CLEANUP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * CLEANUP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master * Add test * fix doc test * Update client/cli/src/logging.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Update client/basic-authorship/src/basic_authorship.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Update client/basic-authorship/src/basic_authorship.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Apply suggestions * Suggestions * Clarify doc * WIP Forked at: d67fc4c2cb6db6fdd2af92909bd13467c20029e5 Parent branch: origin/master Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>

view details

push time in 5 days

PR opened AleoHQ/leo

Arithmetic benchmarks and perf improvements

Builds on https://github.com/AleoHQ/leo/pull/402 in order to limit conflict potential; only the last 7 commits are new and each commit message describes its specific changes.

I've noticed that the integer division tests (especially test_int128_div) have been taking quite some time, so I started looking at ways of possibly improving the performance of arithmetic operations.

There's already 3 perf-targeting commits in the list:

  • perf: make signed_integer's is_constant method faster
  • perf: make Address is_constant method faster
  • perf: remove a redundant clone

And I started working on a benchmark suite in order to be able to find and verify further improvements. Further benchmarks will be incorporated into the last commit, and any further perf improvements will follow up as individual, self-contained commits.

+214 -104

0 comment

19 changed files

pr created time in 5 days

create barnchljedrz/leo

branch : arithmetic_benches

created branch time in 5 days

PR opened AleoHQ/leo

A few post-merge cleanups

After the recent host of PRs there were a few small bits lost in conflicts; this PR includes them, making cargo clippy --workspace --tests --examples --benches clean.

+24 -41

0 comment

8 changed files

pr created time in 6 days

create barnchljedrz/leo

branch : post_merge_cleanup

created branch time in 6 days

delete branch ljedrz/leo

delete branch : boxing_improvements

delete time in 6 days

delete branch ljedrz/leo

delete branch : alloc_hunting

delete time in 6 days

delete branch ljedrz/leo

delete branch : pass_by_reference_compiler_overhaul

delete time in 6 days

delete branch ljedrz/leo

delete branch : type_tweaks

delete time in 6 days

delete branch ljedrz/leo

delete branch : ast_perf

delete time in 6 days

delete branch ljedrz/leo

delete branch : pest_test

delete time in 6 days

delete branch ljedrz/leo

delete branch : clippy_compliance2

delete time in 6 days

delete branch ljedrz/leo

delete branch : clippy_compliance

delete time in 6 days

PR opened AleoHQ/snarkOS

Clippy compliance 1.47

Builds on a rebased https://github.com/AleoHQ/snarkOS/pull/478, only the last 5 commits are new.

The new version of the compiler is bundled with an updated clippy, which was able to find some new issues in the codebase. There are also some new lints, 2 of which can yield performance improvements:

  • match_like_matches_macro, fixed in https://github.com/AleoHQ/snarkOS/commit/54efd538171028741b5bdd0532d0d55967e1207e
  • stable_sort_primitive, handled in https://github.com/AleoHQ/snarkOS/commit/3b1585c948b98227ece9a4e5cf3eaee3c5ee62ef
  • same_item_push (commit https://github.com/AleoHQ/snarkOS/commit/30a1d76325a7ac358e6ebeabfed1ba1248acc0a6)
+244 -358

0 comment

62 changed files

pr created time in 6 days

create barnchljedrz/snarkOS

branch : clippy_compliance4

created branch time in 6 days

push eventljedrz/leo

ljedrz

commit sha 49e9a48d907befe3ce9dc25fba829de0472cb9fc

perf: reduce boxing in typed objects Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

ljedrz

commit sha 648e27b1264fa753639151ec104f87904151e73e

test: make the typed serialization test whitespace-agnostic Signed-off-by: ljedrz <ljedrz@gmail.com>

view details

push time in 6 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Contribution section

 # Contributing / Development -There are several angles that people can take to contribute to this effort.+There are several ways that people can help `offchain::ipfs`. -TODO: Enumerate them+## Create a dApp or custom Substrate pallet, and tell us about it++Now that the proof-of-concept is complete and this manual is published, our goal is to be+laser-focused on user needs and to build out the capabilities of `offchain::ipfs` based on those.+So, **if you end up trying this out, we would love to know how, and for what.**++- Tell us about what you're doing by opening an information issue at [rs-ipfs/substrate]+- Share feedback on this manual by opening an issue at [rs-ipfs/offchain-ipfs-manual]+- Share feedback on `offchain::ipfs` itself by open an issue at [rs-ipfs/substrate]++## Support `offchain::ipfs` financially++[Equilibrium] is a consultancy that builds, and helps you build _on_, the distributed web. If+you're part of an organization and want help implementing or improving `offchain::ipfs`,+get in touch with us.++- If you're an individual and want to support us financially, visit our [OpenCollective].++## Implement more IPFS functionality++Some of the functionality exists in [Rust IPFS] and is not exposed via `offchain::ipfs`, and some
Some of the functionality that exists in [Rust IPFS] is not exposed via `offchain::ipfs`, and some
aphelionz

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Contribution section

 # Contributing / Development -There are several angles that people can take to contribute to this effort.+There are several ways that people can help `offchain::ipfs`. -TODO: Enumerate them+## Create a dApp or custom Substrate pallet, and tell us about it++Now that the proof-of-concept is complete and this manual is published, our goal is to be+laser-focused on user needs and to build out the capabilities of `offchain::ipfs` based on those.+So, **if you end up trying this out, we would love to know how, and for what.**++- Tell us about what you're doing by opening an information issue at [rs-ipfs/substrate]+- Share feedback on this manual by opening an issue at [rs-ipfs/offchain-ipfs-manual]+- Share feedback on `offchain::ipfs` itself by open an issue at [rs-ipfs/substrate]++## Support `offchain::ipfs` financially++[Equilibrium] is a consultancy that builds, and helps you build _on_, the distributed web. If+you're part of an organization and want help implementing or improving `offchain::ipfs`,+get in touch with us.++- If you're an individual and want to support us financially, visit our [OpenCollective].++## Implement more IPFS functionality++Some of the functionality exists in [Rust IPFS] and is not exposed via `offchain::ipfs`, and some+of the functionality is not implemented in Rust IPFS at all. If there's something that another
of the IPFS functionalities are not implemented in Rust IPFS at all. If there's something that another
aphelionz

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Contribution section

 # Contributing / Development -There are several angles that people can take to contribute to this effort.+There are several ways that people can help `offchain::ipfs`. -TODO: Enumerate them+## Create a dApp or custom Substrate pallet, and tell us about it++Now that the proof-of-concept is complete and this manual is published, our goal is to be+laser-focused on user needs and to build out the capabilities of `offchain::ipfs` based on those.+So, **if you end up trying this out, we would love to know how, and for what.**++- Tell us about what you're doing by opening an information issue at [rs-ipfs/substrate]+- Share feedback on this manual by opening an issue at [rs-ipfs/offchain-ipfs-manual]+- Share feedback on `offchain::ipfs` itself by open an issue at [rs-ipfs/substrate]++## Support `offchain::ipfs` financially++[Equilibrium] is a consultancy that builds, and helps you build _on_, the distributed web. If
[Equilibrium] is a consultancy that builds, and helps you build _on_ the distributed web. If

I know what the purpose of that extra comma was, but the sentence is pretty short, so it felt odd

aphelionz

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Contribution section

 # Contributing / Development -There are several angles that people can take to contribute to this effort.+There are several ways that people can help `offchain::ipfs`. -TODO: Enumerate them+## Create a dApp or custom Substrate pallet, and tell us about it++Now that the proof-of-concept is complete and this manual is published, our goal is to be+laser-focused on user needs and to build out the capabilities of `offchain::ipfs` based on those.+So, **if you end up trying this out, we would love to know how, and for what.**++- Tell us about what you're doing by opening an information issue at [rs-ipfs/substrate]+- Share feedback on this manual by opening an issue at [rs-ipfs/offchain-ipfs-manual]+- Share feedback on `offchain::ipfs` itself by open an issue at [rs-ipfs/substrate]
- provide feedback on `offchain::ipfs` itself by opening an issue at [rs-ipfs/substrate]
aphelionz

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Contribution section

 # Contributing / Development -There are several angles that people can take to contribute to this effort.+There are several ways that people can help `offchain::ipfs`. -TODO: Enumerate them+## Create a dApp or custom Substrate pallet, and tell us about it++Now that the proof-of-concept is complete and this manual is published, our goal is to be+laser-focused on user needs and to build out the capabilities of `offchain::ipfs` based on those.+So, **if you end up trying this out, we would love to know how, and for what.**
So, **if you end up trying this out, we would love to know how, and what your use case is.**
aphelionz

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Contribution section

 # Contributing / Development -There are several angles that people can take to contribute to this effort.+There are several ways that people can help `offchain::ipfs`. -TODO: Enumerate them+## Create a dApp or custom Substrate pallet, and tell us about it++Now that the proof-of-concept is complete and this manual is published, our goal is to be+laser-focused on user needs and to build out the capabilities of `offchain::ipfs` based on those.
laser-focused on user needs and to extend the capabilities of `offchain::ipfs` based on them.
aphelionz

comment created time in 6 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Contribution section

 # Contributing / Development -There are several angles that people can take to contribute to this effort.+There are several ways that people can help `offchain::ipfs`. -TODO: Enumerate them+## Create a dApp or custom Substrate pallet, and tell us about it
## Create a dApp or a custom Substrate pallet, and tell us about it
aphelionz

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Fuse code

+use codec::Encode;+use sp_keyring::AccountKeyring;+use substrate_subxt::{Call, ClientBuilder, EventsDecoder, NodeTemplateRuntime, PairSigner};++#[async_std::main]+async fn main() -> Result<(), Box<dyn std::error::Error>> {+    // Signer for the extrinsic+    let signer = PairSigner::<NodeTemplateRuntime, _>::new(AccountKeyring::Alice.pair());+    // API client, default to connect to 127.0.0.1:9944+    let client = ClientBuilder::<NodeTemplateRuntime>::new().build().await?;++    // Example CID for the example bytes added vec![1, 2, 3, 4]+    let cid = String::from("QmRgctVSR8hvGRDLv7c5H7BCji7m1VXRfEE1vW78CFagD7")+        .into_bytes()+        .to_vec();+    // Example multiaddr to connect IPFS with+    let multiaddr = String::from(+        "/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ",+    )+    .into_bytes()+    .to_vec();+    // Example Peer Id+    let peer_id = String::from("QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ")+        .into_bytes()+        .to_vec();

same 3 to_vec() redundant_conversions in the 3 assignments above

whalelephant

comment created time in 7 days

PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Fuse code

+use sp_core::crypto::Pair;+use sp_keyring::AccountKeyring;+use std::{convert::TryFrom, string::String};+use substrate_api_client::{+    compose_call, compose_extrinsic_offline, extrinsic::xt_primitives::UncheckedExtrinsicV4,+    node_metadata::Metadata, Api, XtStatus,+};++fn main() {+    // instantiate an Api that connects to the given address+    let url = "127.0.0.1:9944";+    // if no signer is set in the whole program, we need to give to Api a specific type instead of an associated type+    // as during compilation the type needs to be defined.+    let signer = AccountKeyring::Bob.pair();++    // sets up api client and retrieves the node metadata+    let api = Api::new(format!("ws://{}", url)).set_signer(signer.clone());+    // gets the current nonce of Bob so we can increment it manually later+    let mut nonce = api.get_nonce().unwrap();++    // data from the node required in extrinsic+    let meta = Metadata::try_from(api.get_metadata()).unwrap();+    let genesis_hash = api.genesis_hash;+    let spec_version = api.runtime_version.spec_version;+    let transaction_version = api.runtime_version.transaction_version;++    // Example bytes to add+    let bytes_to_add: Vec<u8> = vec![1, 2, 3, 4];+    // Example CID for the example bytes added vec![1, 2, 3, 4]+    let cid = String::from("QmRgctVSR8hvGRDLv7c5H7BCji7m1VXRfEE1vW78CFagD7")+        .into_bytes()+        .to_vec();+    // Example multiaddr to connect IPFS with+    let multiaddr = String::from(+        "/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ",+    )+    .into_bytes()+    .to_vec();+    // Example Peer Id+    let peer_id = String::from("QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ")+        .into_bytes()+        .to_vec();

same

whalelephant

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Fuse code

+use sp_core::crypto::Pair;+use sp_keyring::AccountKeyring;+use std::{convert::TryFrom, string::String};+use substrate_api_client::{+    compose_call, compose_extrinsic_offline, extrinsic::xt_primitives::UncheckedExtrinsicV4,+    node_metadata::Metadata, Api, XtStatus,+};++fn main() {+    // instantiate an Api that connects to the given address+    let url = "127.0.0.1:9944";+    // if no signer is set in the whole program, we need to give to Api a specific type instead of an associated type+    // as during compilation the type needs to be defined.+    let signer = AccountKeyring::Bob.pair();++    // sets up api client and retrieves the node metadata+    let api = Api::new(format!("ws://{}", url)).set_signer(signer.clone());+    // gets the current nonce of Bob so we can increment it manually later+    let mut nonce = api.get_nonce().unwrap();++    // data from the node required in extrinsic+    let meta = Metadata::try_from(api.get_metadata()).unwrap();+    let genesis_hash = api.genesis_hash;+    let spec_version = api.runtime_version.spec_version;+    let transaction_version = api.runtime_version.transaction_version;++    // Example bytes to add+    let bytes_to_add: Vec<u8> = vec![1, 2, 3, 4];+    // Example CID for the example bytes added vec![1, 2, 3, 4]+    let cid = String::from("QmRgctVSR8hvGRDLv7c5H7BCji7m1VXRfEE1vW78CFagD7")+        .into_bytes()+        .to_vec();+    // Example multiaddr to connect IPFS with+    let multiaddr = String::from(+        "/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ",+    )+    .into_bytes()+    .to_vec();

ditto

whalelephant

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Fuse code

+use sp_core::crypto::Pair;+use sp_keyring::AccountKeyring;+use std::{convert::TryFrom, string::String};+use substrate_api_client::{+    compose_call, compose_extrinsic_offline, extrinsic::xt_primitives::UncheckedExtrinsicV4,+    node_metadata::Metadata, Api, XtStatus,+};++fn main() {+    // instantiate an Api that connects to the given address+    let url = "127.0.0.1:9944";+    // if no signer is set in the whole program, we need to give to Api a specific type instead of an associated type+    // as during compilation the type needs to be defined.+    let signer = AccountKeyring::Bob.pair();++    // sets up api client and retrieves the node metadata+    let api = Api::new(format!("ws://{}", url)).set_signer(signer.clone());+    // gets the current nonce of Bob so we can increment it manually later+    let mut nonce = api.get_nonce().unwrap();++    // data from the node required in extrinsic+    let meta = Metadata::try_from(api.get_metadata()).unwrap();+    let genesis_hash = api.genesis_hash;+    let spec_version = api.runtime_version.spec_version;+    let transaction_version = api.runtime_version.transaction_version;++    // Example bytes to add+    let bytes_to_add: Vec<u8> = vec![1, 2, 3, 4];+    // Example CID for the example bytes added vec![1, 2, 3, 4]+    let cid = String::from("QmRgctVSR8hvGRDLv7c5H7BCji7m1VXRfEE1vW78CFagD7")+        .into_bytes()+        .to_vec();

this should be redundant after into_bytes()

whalelephant

comment created time in 7 days

PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as+a queue, to be ingested by your native runtime and passed to IPFS.++Derive attributes are omitted.++```rust,ignore+// Commands involved in peer-to-peer connections+enum ConnectionCommand {+    ConnectTo(OpaqueMultiaddr),+    DisconnectFrom(OpaqueMultiaddr),+}++// Commands that add, remove, pin, unpin, and output data+enum DataCommand {+    AddBytes(Vec<u8>),+    CatBytes(Vec<u8>),+    InsertPin(Vec<u8>),+    RemoveBlock(Vec<u8>),+    RemovePin(Vec<u8>),+}++// Commands that query the distributed hash table (DHT)+// for peers and content+enum DhtCommand {+    FindPeer(Vec<u8>),+    GetProviders(Vec<u8>),+}+```++## The runtime configuration trait++The `system::Trait` trait (not to be confused with the Rust `trait` keyword), allows you to define+which capabilities from the runtime you want to include, and how you want to use them. You can also+"tightly couple" your pallet to other pallets by adding their `Trait`s to your pallet's+inherited trait list.++Here, however, we keep things simple by:++1. Loosely coupling this pallet by leaving out inherited traits+2. Including only the required `Event` type++```rust,ignore+/// The pallet's configuration trait.+pub trait Trait: system::Trait { // Use traits here to tightly couple to runtime+    /// The overarching event type.+    type Event: From<Event<Self>> + Into<<Self as system::Trait>::Event>;+}+```++Later in the code, we implement some helper functions on this trait. The function bodies are+omitted for brevity's sake.++```rust,ignore+impl<T: Trait> Module<T> {+    // "Sends" a request to the local IPFS node by adding it to the offchain storage+    fn ipfs_request(req: IpfsRequest, deadline: impl Into<Option<Timestamp>>)+      -> Result<IpfsResponse, Error<T>>++    // Reads from the `ConnectionQueue` and connects / disconnects+    // from desired / undesired peers, respectively+    fn connection_housekeeping() -> Result<(), Error<T>>++    // Reads `FindPeer` and `GetProviders` commands from the `DhtQueue`,+    // and requests their execution from the native runtime+    fn handle_dht_requests() -> Result<(), Error<T>>++    // Reads `AddBytes`, `CatBytes`, `DataCommand`, `RemoveBlock`, `InsertPin`,+    // and `RemovePin` commands from the `DataQueue` and requests their+    // execution from the native runtime.+    fn handle_data_requests() -> Result<(), Error<T>>++    // Logs metadata (the number of connected peers) to the console at the DEBUG log level+    fn print_metadata() -> Result<(), Error<T>>+```++## The `decl_` macros++Pallets included in Substrate runtimes must adhere to the conventions of [FRAME].+In practice, this means you must implement `decl_` macros:++- `decl_module!`+- `decl_event!`+- `decl_storage!`+- `decl_error!`++[FRAME]: https://substrate.dev/docs/en/knowledgebase/runtime/frame+++### `decl_storage!`++Here, we define the data that will actually be stored on-chain as **extrinsics**.++Since the offchain-worker can't perform I/O outside of the wasm context, we store our requests as+queues, to be processed on a periodic basis, consumed, and ultimately performed by the native+runtime.++This is where we use the `ConnectionQueue`, `DataQueue`, and `DhtQueue` command types from above.++```rust,ignore+// This pallet's storage items.+decl_storage! {+    trait Store for Module<T: Trait> as TemplateModule {+        // A list of addresses to connect to and disconnect from.+        pub ConnectionQueue: Vec<ConnectionCommand>;+        // A queue of data to publish or obtain on IPFS.+        pub DataQueue: Vec<DataCommand>;+        // A list of requests to the DHT.+        pub DhtQueue: Vec<DhtCommand>;+    }+}+```++### `decl_event!`++This is where we define what those events are, when they happen, and what they contain.++Once a command is received by the off-chain worker, the corresponding handler from the `decl_module!`
Once a command is sent to the offchain worker, one of the following chain events is emitted.
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as+a queue, to be ingested by your native runtime and passed to IPFS.++Derive attributes are omitted.++```rust,ignore+// Commands involved in peer-to-peer connections+enum ConnectionCommand {+    ConnectTo(OpaqueMultiaddr),+    DisconnectFrom(OpaqueMultiaddr),+}++// Commands that add, remove, pin, unpin, and output data+enum DataCommand {+    AddBytes(Vec<u8>),+    CatBytes(Vec<u8>),+    InsertPin(Vec<u8>),+    RemoveBlock(Vec<u8>),+    RemovePin(Vec<u8>),+}++// Commands that query the distributed hash table (DHT)+// for peers and content+enum DhtCommand {+    FindPeer(Vec<u8>),+    GetProviders(Vec<u8>),+}+```++## The runtime configuration trait++The `system::Trait` trait (not to be confused with the Rust `trait` keyword), allows you to define+which capabilities from the runtime you want to include, and how you want to use them. You can also+"tightly couple" your pallet to other pallets by adding their `Trait`s to your pallet's+inherited trait list.++Here, however, we keep things simple by:++1. Loosely coupling this pallet by leaving out inherited traits+2. Including only the required `Event` type++```rust,ignore+/// The pallet's configuration trait.+pub trait Trait: system::Trait { // Use traits here to tightly couple to runtime+    /// The overarching event type.+    type Event: From<Event<Self>> + Into<<Self as system::Trait>::Event>;+}+```++Later in the code, we implement some helper functions on this trait. The function bodies are+omitted for brevity's sake.++```rust,ignore+impl<T: Trait> Module<T> {+    // "Sends" a request to the local IPFS node by adding it to the offchain storage+    fn ipfs_request(req: IpfsRequest, deadline: impl Into<Option<Timestamp>>)+      -> Result<IpfsResponse, Error<T>>++    // Reads from the `ConnectionQueue` and connects / disconnects+    // from desired / undesired peers, respectively+    fn connection_housekeeping() -> Result<(), Error<T>>++    // Reads `FindPeer` and `GetProviders` commands from the `DhtQueue`,+    // and requests their execution from the native runtime+    fn handle_dht_requests() -> Result<(), Error<T>>++    // Reads `AddBytes`, `CatBytes`, `DataCommand`, `RemoveBlock`, `InsertPin`,+    // and `RemovePin` commands from the `DataQueue` and requests their+    // execution from the native runtime.+    fn handle_data_requests() -> Result<(), Error<T>>++    // Logs metadata (the number of connected peers) to the console at the DEBUG log level+    fn print_metadata() -> Result<(), Error<T>>+```++## The `decl_` macros++Pallets included in Substrate runtimes must adhere to the conventions of [FRAME].+In practice, this means you must implement `decl_` macros:++- `decl_module!`+- `decl_event!`+- `decl_storage!`+- `decl_error!`++[FRAME]: https://substrate.dev/docs/en/knowledgebase/runtime/frame+++### `decl_storage!`++Here, we define the data that will actually be stored on-chain as **extrinsics**.++Since the offchain-worker can't perform I/O outside of the wasm context, we store our requests as+queues, to be processed on a periodic basis, consumed, and ultimately performed by the native+runtime.++This is where we use the `ConnectionQueue`, `DataQueue`, and `DhtQueue` command types from above.++```rust,ignore+// This pallet's storage items.+decl_storage! {+    trait Store for Module<T: Trait> as TemplateModule {+        // A list of addresses to connect to and disconnect from.+        pub ConnectionQueue: Vec<ConnectionCommand>;+        // A queue of data to publish or obtain on IPFS.+        pub DataQueue: Vec<DataCommand>;+        // A list of requests to the DHT.+        pub DhtQueue: Vec<DhtCommand>;+    }+}+```++### `decl_event!`++This is where we define what those events are, when they happen, and what they contain.++Once a command is received by the off-chain worker, the corresponding handler from the `decl_module!`+section will "deposit" the event in its storage, to be processed by the native runtime.++```rust,ignore+// The pallet's events+decl_event!(+    pub enum Event<T> where AccountId = <T as system::Trait>::AccountId {+        ConnectionRequested(AccountId),+        DisconnectRequested(AccountId),+        QueuedDataToAdd(AccountId),+        QueuedDataToCat(AccountId),+        QueuedDataToPin(AccountId),+        QueuedDataToRemove(AccountId),+        QueuedDataToUnpin(AccountId),+        FindPeerIssued(AccountId),+        FindProvidersIssued(AccountId),+    }+);+```++### `decl_module!`++This section, perhaps the most critical section of any given pallet, is where you can define+functions that are exposed as via JSON-RPC to client libraries and, by proxy, your users.++In practice, the bulk of what these functions do is to modify the `DataQueue`, `DhtQueue`, and
In practice, the bulk of what these functions do is modify the `DataQueue`, `DhtQueue`, and
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as+a queue, to be ingested by your native runtime and passed to IPFS.++Derive attributes are omitted.++```rust,ignore+// Commands involved in peer-to-peer connections+enum ConnectionCommand {+    ConnectTo(OpaqueMultiaddr),+    DisconnectFrom(OpaqueMultiaddr),+}++// Commands that add, remove, pin, unpin, and output data+enum DataCommand {+    AddBytes(Vec<u8>),+    CatBytes(Vec<u8>),+    InsertPin(Vec<u8>),+    RemoveBlock(Vec<u8>),+    RemovePin(Vec<u8>),+}++// Commands that query the distributed hash table (DHT)+// for peers and content+enum DhtCommand {+    FindPeer(Vec<u8>),+    GetProviders(Vec<u8>),+}+```++## The runtime configuration trait++The `system::Trait` trait (not to be confused with the Rust `trait` keyword), allows you to define+which capabilities from the runtime you want to include, and how you want to use them. You can also+"tightly couple" your pallet to other pallets by adding their `Trait`s to your pallet's+inherited trait list.++Here, however, we keep things simple by:++1. Loosely coupling this pallet by leaving out inherited traits+2. Including only the required `Event` type++```rust,ignore+/// The pallet's configuration trait.+pub trait Trait: system::Trait { // Use traits here to tightly couple to runtime+    /// The overarching event type.+    type Event: From<Event<Self>> + Into<<Self as system::Trait>::Event>;+}+```++Later in the code, we implement some helper functions on this trait. The function bodies are+omitted for brevity's sake.++```rust,ignore+impl<T: Trait> Module<T> {+    // "Sends" a request to the local IPFS node by adding it to the offchain storage+    fn ipfs_request(req: IpfsRequest, deadline: impl Into<Option<Timestamp>>)+      -> Result<IpfsResponse, Error<T>>++    // Reads from the `ConnectionQueue` and connects / disconnects+    // from desired / undesired peers, respectively+    fn connection_housekeeping() -> Result<(), Error<T>>++    // Reads `FindPeer` and `GetProviders` commands from the `DhtQueue`,+    // and requests their execution from the native runtime+    fn handle_dht_requests() -> Result<(), Error<T>>++    // Reads `AddBytes`, `CatBytes`, `DataCommand`, `RemoveBlock`, `InsertPin`,+    // and `RemovePin` commands from the `DataQueue` and requests their+    // execution from the native runtime.+    fn handle_data_requests() -> Result<(), Error<T>>++    // Logs metadata (the number of connected peers) to the console at the DEBUG log level+    fn print_metadata() -> Result<(), Error<T>>+```++## The `decl_` macros++Pallets included in Substrate runtimes must adhere to the conventions of [FRAME].+In practice, this means you must implement `decl_` macros:++- `decl_module!`+- `decl_event!`+- `decl_storage!`+- `decl_error!`++[FRAME]: https://substrate.dev/docs/en/knowledgebase/runtime/frame+++### `decl_storage!`++Here, we define the data that will actually be stored on-chain as **extrinsics**.++Since the offchain-worker can't perform I/O outside of the wasm context, we store our requests as+queues, to be processed on a periodic basis, consumed, and ultimately performed by the native+runtime.++This is where we use the `ConnectionQueue`, `DataQueue`, and `DhtQueue` command types from above.++```rust,ignore+// This pallet's storage items.+decl_storage! {+    trait Store for Module<T: Trait> as TemplateModule {+        // A list of addresses to connect to and disconnect from.+        pub ConnectionQueue: Vec<ConnectionCommand>;+        // A queue of data to publish or obtain on IPFS.+        pub DataQueue: Vec<DataCommand>;+        // A list of requests to the DHT.+        pub DhtQueue: Vec<DhtCommand>;+    }+}+```++### `decl_event!`++This is where we define what those events are, when they happen, and what they contain.++Once a command is received by the off-chain worker, the corresponding handler from the `decl_module!`+section will "deposit" the event in its storage, to be processed by the native runtime.++```rust,ignore+// The pallet's events+decl_event!(+    pub enum Event<T> where AccountId = <T as system::Trait>::AccountId {+        ConnectionRequested(AccountId),+        DisconnectRequested(AccountId),+        QueuedDataToAdd(AccountId),+        QueuedDataToCat(AccountId),+        QueuedDataToPin(AccountId),+        QueuedDataToRemove(AccountId),+        QueuedDataToUnpin(AccountId),+        FindPeerIssued(AccountId),+        FindProvidersIssued(AccountId),+    }+);+```++### `decl_module!`++This section, perhaps the most critical section of any given pallet, is where you can define+functions that are exposed as via JSON-RPC to client libraries and, by proxy, your users.++In practice, the bulk of what these functions do is to modify the `DataQueue`, `DhtQueue`, and+`ConnectionQueue` storage objects by pushing signed command requests to their respective queues.++Some default types functions are omitted, but we've kept the `#[weight]` attributes around.++> The Substrate docs define defines one unit of weight as "one picosecond of execution time on+fixed reference hardware." These are essentially _time limits_ for block creation, and can be+(indirectly) mapped to transaction fees analogous to something like "gas fees." Read more about
(indirectly) mapped to transaction fees analogous to something like "gas fees". Read more about
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,
their arguments and return values. As explained in the section on the example pallet,
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as+a queue, to be ingested by your native runtime and passed to IPFS.++Derive attributes are omitted.++```rust,ignore+// Commands involved in peer-to-peer connections+enum ConnectionCommand {+    ConnectTo(OpaqueMultiaddr),+    DisconnectFrom(OpaqueMultiaddr),+}++// Commands that add, remove, pin, unpin, and output data+enum DataCommand {+    AddBytes(Vec<u8>),+    CatBytes(Vec<u8>),+    InsertPin(Vec<u8>),+    RemoveBlock(Vec<u8>),+    RemovePin(Vec<u8>),+}++// Commands that query the distributed hash table (DHT)+// for peers and content+enum DhtCommand {+    FindPeer(Vec<u8>),+    GetProviders(Vec<u8>),+}+```++## The runtime configuration trait++The `system::Trait` trait (not to be confused with the Rust `trait` keyword), allows you to define+which capabilities from the runtime you want to include, and how you want to use them. You can also+"tightly couple" your pallet to other pallets by adding their `Trait`s to your pallet's+inherited trait list.++Here, however, we keep things simple by:++1. Loosely coupling this pallet by leaving out inherited traits+2. Including only the required `Event` type++```rust,ignore+/// The pallet's configuration trait.+pub trait Trait: system::Trait { // Use traits here to tightly couple to runtime+    /// The overarching event type.+    type Event: From<Event<Self>> + Into<<Self as system::Trait>::Event>;+}+```++Later in the code, we implement some helper functions on this trait. The function bodies are+omitted for brevity's sake.++```rust,ignore+impl<T: Trait> Module<T> {+    // "Sends" a request to the local IPFS node by adding it to the offchain storage+    fn ipfs_request(req: IpfsRequest, deadline: impl Into<Option<Timestamp>>)+      -> Result<IpfsResponse, Error<T>>++    // Reads from the `ConnectionQueue` and connects / disconnects+    // from desired / undesired peers, respectively+    fn connection_housekeeping() -> Result<(), Error<T>>++    // Reads `FindPeer` and `GetProviders` commands from the `DhtQueue`,+    // and requests their execution from the native runtime+    fn handle_dht_requests() -> Result<(), Error<T>>++    // Reads `AddBytes`, `CatBytes`, `DataCommand`, `RemoveBlock`, `InsertPin`,+    // and `RemovePin` commands from the `DataQueue` and requests their+    // execution from the native runtime.+    fn handle_data_requests() -> Result<(), Error<T>>++    // Logs metadata (the number of connected peers) to the console at the DEBUG log level+    fn print_metadata() -> Result<(), Error<T>>+```++## The `decl_` macros++Pallets included in Substrate runtimes must adhere to the conventions of [FRAME].+In practice, this means you must implement `decl_` macros:++- `decl_module!`+- `decl_event!`+- `decl_storage!`+- `decl_error!`++[FRAME]: https://substrate.dev/docs/en/knowledgebase/runtime/frame+++### `decl_storage!`++Here, we define the data that will actually be stored on-chain as **extrinsics**.++Since the offchain-worker can't perform I/O outside of the wasm context, we store our requests as+queues, to be processed on a periodic basis, consumed, and ultimately performed by the native+runtime.++This is where we use the `ConnectionQueue`, `DataQueue`, and `DhtQueue` command types from above.++```rust,ignore+// This pallet's storage items.+decl_storage! {+    trait Store for Module<T: Trait> as TemplateModule {+        // A list of addresses to connect to and disconnect from.+        pub ConnectionQueue: Vec<ConnectionCommand>;+        // A queue of data to publish or obtain on IPFS.+        pub DataQueue: Vec<DataCommand>;+        // A list of requests to the DHT.+        pub DhtQueue: Vec<DhtCommand>;+    }+}+```++### `decl_event!`++This is where we define what those events are, when they happen, and what they contain.++Once a command is received by the off-chain worker, the corresponding handler from the `decl_module!`+section will "deposit" the event in its storage, to be processed by the native runtime.++```rust,ignore+// The pallet's events+decl_event!(+    pub enum Event<T> where AccountId = <T as system::Trait>::AccountId {+        ConnectionRequested(AccountId),+        DisconnectRequested(AccountId),+        QueuedDataToAdd(AccountId),+        QueuedDataToCat(AccountId),+        QueuedDataToPin(AccountId),+        QueuedDataToRemove(AccountId),+        QueuedDataToUnpin(AccountId),+        FindPeerIssued(AccountId),+        FindProvidersIssued(AccountId),+    }+);+```++### `decl_module!`++This section, perhaps the most critical section of any given pallet, is where you can define+functions that are exposed as via JSON-RPC to client libraries and, by proxy, your users.++In practice, the bulk of what these functions do is to modify the `DataQueue`, `DhtQueue`, and+`ConnectionQueue` storage objects by pushing signed command requests to their respective queues.++Some default types functions are omitted, but we've kept the `#[weight]` attributes around.++> The Substrate docs define defines one unit of weight as "one picosecond of execution time on+fixed reference hardware." These are essentially _time limits_ for block creation, and can be
fixed reference hardware". These are essentially _time limits_ for block creation, and can be
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as+a queue, to be ingested by your native runtime and passed to IPFS.++Derive attributes are omitted.++```rust,ignore+// Commands involved in peer-to-peer connections+enum ConnectionCommand {+    ConnectTo(OpaqueMultiaddr),+    DisconnectFrom(OpaqueMultiaddr),+}++// Commands that add, remove, pin, unpin, and output data+enum DataCommand {+    AddBytes(Vec<u8>),+    CatBytes(Vec<u8>),+    InsertPin(Vec<u8>),+    RemoveBlock(Vec<u8>),+    RemovePin(Vec<u8>),+}++// Commands that query the distributed hash table (DHT)+// for peers and content+enum DhtCommand {+    FindPeer(Vec<u8>),+    GetProviders(Vec<u8>),+}+```++## The runtime configuration trait++The `system::Trait` trait (not to be confused with the Rust `trait` keyword), allows you to define+which capabilities from the runtime you want to include, and how you want to use them. You can also+"tightly couple" your pallet to other pallets by adding their `Trait`s to your pallet's+inherited trait list.++Here, however, we keep things simple by:++1. Loosely coupling this pallet by leaving out inherited traits+2. Including only the required `Event` type++```rust,ignore+/// The pallet's configuration trait.+pub trait Trait: system::Trait { // Use traits here to tightly couple to runtime+    /// The overarching event type.+    type Event: From<Event<Self>> + Into<<Self as system::Trait>::Event>;+}+```++Later in the code, we implement some helper functions on this trait. The function bodies are+omitted for brevity's sake.++```rust,ignore+impl<T: Trait> Module<T> {+    // "Sends" a request to the local IPFS node by adding it to the offchain storage+    fn ipfs_request(req: IpfsRequest, deadline: impl Into<Option<Timestamp>>)+      -> Result<IpfsResponse, Error<T>>++    // Reads from the `ConnectionQueue` and connects / disconnects+    // from desired / undesired peers, respectively+    fn connection_housekeeping() -> Result<(), Error<T>>++    // Reads `FindPeer` and `GetProviders` commands from the `DhtQueue`,+    // and requests their execution from the native runtime+    fn handle_dht_requests() -> Result<(), Error<T>>++    // Reads `AddBytes`, `CatBytes`, `DataCommand`, `RemoveBlock`, `InsertPin`,+    // and `RemovePin` commands from the `DataQueue` and requests their+    // execution from the native runtime.+    fn handle_data_requests() -> Result<(), Error<T>>++    // Logs metadata (the number of connected peers) to the console at the DEBUG log level+    fn print_metadata() -> Result<(), Error<T>>+```++## The `decl_` macros++Pallets included in Substrate runtimes must adhere to the conventions of [FRAME].+In practice, this means you must implement `decl_` macros:++- `decl_module!`+- `decl_event!`+- `decl_storage!`+- `decl_error!`++[FRAME]: https://substrate.dev/docs/en/knowledgebase/runtime/frame+++### `decl_storage!`++Here, we define the data that will actually be stored on-chain as **extrinsics**.++Since the offchain-worker can't perform I/O outside of the wasm context, we store our requests as+queues, to be processed on a periodic basis, consumed, and ultimately performed by the native+runtime.++This is where we use the `ConnectionQueue`, `DataQueue`, and `DhtQueue` command types from above.++```rust,ignore+// This pallet's storage items.+decl_storage! {+    trait Store for Module<T: Trait> as TemplateModule {+        // A list of addresses to connect to and disconnect from.+        pub ConnectionQueue: Vec<ConnectionCommand>;+        // A queue of data to publish or obtain on IPFS.+        pub DataQueue: Vec<DataCommand>;+        // A list of requests to the DHT.+        pub DhtQueue: Vec<DhtCommand>;+    }+}+```++### `decl_event!`++This is where we define what those events are, when they happen, and what they contain.++Once a command is received by the off-chain worker, the corresponding handler from the `decl_module!`+section will "deposit" the event in its storage, to be processed by the native runtime.++```rust,ignore+// The pallet's events+decl_event!(+    pub enum Event<T> where AccountId = <T as system::Trait>::AccountId {+        ConnectionRequested(AccountId),+        DisconnectRequested(AccountId),+        QueuedDataToAdd(AccountId),+        QueuedDataToCat(AccountId),+        QueuedDataToPin(AccountId),+        QueuedDataToRemove(AccountId),+        QueuedDataToUnpin(AccountId),+        FindPeerIssued(AccountId),+        FindProvidersIssued(AccountId),+    }+);+```++### `decl_module!`++This section, perhaps the most critical section of any given pallet, is where you can define+functions that are exposed as via JSON-RPC to client libraries and, by proxy, your users.++In practice, the bulk of what these functions do is to modify the `DataQueue`, `DhtQueue`, and+`ConnectionQueue` storage objects by pushing signed command requests to their respective queues.++Some default types functions are omitted, but we've kept the `#[weight]` attributes around.++> The Substrate docs define defines one unit of weight as "one picosecond of execution time on
> The Substrate docs define one unit of weight as "one picosecond of execution time on
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as+a queue, to be ingested by your native runtime and passed to IPFS.++Derive attributes are omitted.++```rust,ignore+// Commands involved in peer-to-peer connections+enum ConnectionCommand {+    ConnectTo(OpaqueMultiaddr),+    DisconnectFrom(OpaqueMultiaddr),+}++// Commands that add, remove, pin, unpin, and output data+enum DataCommand {+    AddBytes(Vec<u8>),+    CatBytes(Vec<u8>),+    InsertPin(Vec<u8>),+    RemoveBlock(Vec<u8>),+    RemovePin(Vec<u8>),+}++// Commands that query the distributed hash table (DHT)+// for peers and content+enum DhtCommand {+    FindPeer(Vec<u8>),+    GetProviders(Vec<u8>),+}+```++## The runtime configuration trait++The `system::Trait` trait (not to be confused with the Rust `trait` keyword), allows you to define+which capabilities from the runtime you want to include, and how you want to use them. You can also+"tightly couple" your pallet to other pallets by adding their `Trait`s to your pallet's+inherited trait list.++Here, however, we keep things simple by:++1. Loosely coupling this pallet by leaving out inherited traits+2. Including only the required `Event` type++```rust,ignore+/// The pallet's configuration trait.+pub trait Trait: system::Trait { // Use traits here to tightly couple to runtime+    /// The overarching event type.+    type Event: From<Event<Self>> + Into<<Self as system::Trait>::Event>;+}+```++Later in the code, we implement some helper functions on this trait. The function bodies are+omitted for brevity's sake.++```rust,ignore+impl<T: Trait> Module<T> {+    // "Sends" a request to the local IPFS node by adding it to the offchain storage+    fn ipfs_request(req: IpfsRequest, deadline: impl Into<Option<Timestamp>>)+      -> Result<IpfsResponse, Error<T>>++    // Reads from the `ConnectionQueue` and connects / disconnects+    // from desired / undesired peers, respectively+    fn connection_housekeeping() -> Result<(), Error<T>>++    // Reads `FindPeer` and `GetProviders` commands from the `DhtQueue`,+    // and requests their execution from the native runtime+    fn handle_dht_requests() -> Result<(), Error<T>>++    // Reads `AddBytes`, `CatBytes`, `DataCommand`, `RemoveBlock`, `InsertPin`,+    // and `RemovePin` commands from the `DataQueue` and requests their+    // execution from the native runtime.+    fn handle_data_requests() -> Result<(), Error<T>>++    // Logs metadata (the number of connected peers) to the console at the DEBUG log level+    fn print_metadata() -> Result<(), Error<T>>+```++## The `decl_` macros++Pallets included in Substrate runtimes must adhere to the conventions of [FRAME].+In practice, this means you must implement `decl_` macros:++- `decl_module!`+- `decl_event!`+- `decl_storage!`+- `decl_error!`++[FRAME]: https://substrate.dev/docs/en/knowledgebase/runtime/frame+++### `decl_storage!`++Here, we define the data that will actually be stored on-chain as **extrinsics**.++Since the offchain-worker can't perform I/O outside of the wasm context, we store our requests as+queues, to be processed on a periodic basis, consumed, and ultimately performed by the native+runtime.++This is where we use the `ConnectionQueue`, `DataQueue`, and `DhtQueue` command types from above.++```rust,ignore+// This pallet's storage items.+decl_storage! {+    trait Store for Module<T: Trait> as TemplateModule {+        // A list of addresses to connect to and disconnect from.+        pub ConnectionQueue: Vec<ConnectionCommand>;+        // A queue of data to publish or obtain on IPFS.+        pub DataQueue: Vec<DataCommand>;+        // A list of requests to the DHT.+        pub DhtQueue: Vec<DhtCommand>;+    }+}+```++### `decl_event!`++This is where we define what those events are, when they happen, and what they contain.++Once a command is received by the off-chain worker, the corresponding handler from the `decl_module!`+section will "deposit" the event in its storage, to be processed by the native runtime.
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as+a queue, to be ingested by your native runtime and passed to IPFS.++Derive attributes are omitted.++```rust,ignore+// Commands involved in peer-to-peer connections+enum ConnectionCommand {+    ConnectTo(OpaqueMultiaddr),+    DisconnectFrom(OpaqueMultiaddr),+}++// Commands that add, remove, pin, unpin, and output data+enum DataCommand {+    AddBytes(Vec<u8>),+    CatBytes(Vec<u8>),+    InsertPin(Vec<u8>),+    RemoveBlock(Vec<u8>),+    RemovePin(Vec<u8>),+}++// Commands that query the distributed hash table (DHT)+// for peers and content+enum DhtCommand {+    FindPeer(Vec<u8>),+    GetProviders(Vec<u8>),+}+```++## The runtime configuration trait++The `system::Trait` trait (not to be confused with the Rust `trait` keyword), allows you to define+which capabilities from the runtime you want to include, and how you want to use them. You can also+"tightly couple" your pallet to other pallets by adding their `Trait`s to your pallet's+inherited trait list.++Here, however, we keep things simple by:++1. Loosely coupling this pallet by leaving out inherited traits+2. Including only the required `Event` type++```rust,ignore+/// The pallet's configuration trait.+pub trait Trait: system::Trait { // Use traits here to tightly couple to runtime+    /// The overarching event type.+    type Event: From<Event<Self>> + Into<<Self as system::Trait>::Event>;+}+```++Later in the code, we implement some helper functions on this trait. The function bodies are+omitted for brevity's sake.++```rust,ignore+impl<T: Trait> Module<T> {+    // "Sends" a request to the local IPFS node by adding it to the offchain storage+    fn ipfs_request(req: IpfsRequest, deadline: impl Into<Option<Timestamp>>)+      -> Result<IpfsResponse, Error<T>>++    // Reads from the `ConnectionQueue` and connects / disconnects+    // from desired / undesired peers, respectively+    fn connection_housekeeping() -> Result<(), Error<T>>++    // Reads `FindPeer` and `GetProviders` commands from the `DhtQueue`,+    // and requests their execution from the native runtime+    fn handle_dht_requests() -> Result<(), Error<T>>++    // Reads `AddBytes`, `CatBytes`, `DataCommand`, `RemoveBlock`, `InsertPin`,+    // and `RemovePin` commands from the `DataQueue` and requests their+    // execution from the native runtime.+    fn handle_data_requests() -> Result<(), Error<T>>++    // Logs metadata (the number of connected peers) to the console at the DEBUG log level+    fn print_metadata() -> Result<(), Error<T>>+```++## The `decl_` macros++Pallets included in Substrate runtimes must adhere to the conventions of [FRAME].+In practice, this means you must implement `decl_` macros:++- `decl_module!`+- `decl_event!`+- `decl_storage!`+- `decl_error!`++[FRAME]: https://substrate.dev/docs/en/knowledgebase/runtime/frame+++### `decl_storage!`++Here, we define the data that will actually be stored on-chain as **extrinsics**.++Since the offchain-worker can't perform I/O outside of the wasm context, we store our requests as+queues, to be processed on a periodic basis, consumed, and ultimately performed by the native+runtime.++This is where we use the `ConnectionQueue`, `DataQueue`, and `DhtQueue` command types from above.++```rust,ignore+// This pallet's storage items.+decl_storage! {+    trait Store for Module<T: Trait> as TemplateModule {+        // A list of addresses to connect to and disconnect from.+        pub ConnectionQueue: Vec<ConnectionCommand>;+        // A queue of data to publish or obtain on IPFS.+        pub DataQueue: Vec<DataCommand>;+        // A list of requests to the DHT.+        pub DhtQueue: Vec<DhtCommand>;+    }+}+```++### `decl_event!`++This is where we define what those events are, when they happen, and what they contain.++Once a command is received by the off-chain worker, the corresponding handler from the `decl_module!`+section will "deposit" the event in its storage, to be processed by the native runtime.++```rust,ignore+// The pallet's events+decl_event!(+    pub enum Event<T> where AccountId = <T as system::Trait>::AccountId {+        ConnectionRequested(AccountId),+        DisconnectRequested(AccountId),+        QueuedDataToAdd(AccountId),+        QueuedDataToCat(AccountId),+        QueuedDataToPin(AccountId),+        QueuedDataToRemove(AccountId),+        QueuedDataToUnpin(AccountId),+        FindPeerIssued(AccountId),+        FindProvidersIssued(AccountId),+    }+);+```++### `decl_module!`++This section, perhaps the most critical section of any given pallet, is where you can define+functions that are exposed as via JSON-RPC to client libraries and, by proxy, your users.++In practice, the bulk of what these functions do is to modify the `DataQueue`, `DhtQueue`, and+`ConnectionQueue` storage objects by pushing signed command requests to their respective queues.++Some default types functions are omitted, but we've kept the `#[weight]` attributes around.
Some default types in the functions are omitted, but we've kept the `#[weight]` attributes around.
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as+a queue, to be ingested by your native runtime and passed to IPFS.++Derive attributes are omitted.++```rust,ignore+// Commands involved in peer-to-peer connections+enum ConnectionCommand {+    ConnectTo(OpaqueMultiaddr),+    DisconnectFrom(OpaqueMultiaddr),+}++// Commands that add, remove, pin, unpin, and output data+enum DataCommand {+    AddBytes(Vec<u8>),+    CatBytes(Vec<u8>),+    InsertPin(Vec<u8>),+    RemoveBlock(Vec<u8>),+    RemovePin(Vec<u8>),+}++// Commands that query the distributed hash table (DHT)+// for peers and content+enum DhtCommand {+    FindPeer(Vec<u8>),+    GetProviders(Vec<u8>),+}+```++## The runtime configuration trait++The `system::Trait` trait (not to be confused with the Rust `trait` keyword), allows you to define+which capabilities from the runtime you want to include, and how you want to use them. You can also+"tightly couple" your pallet to other pallets by adding their `Trait`s to your pallet's+inherited trait list.++Here, however, we keep things simple by:++1. Loosely coupling this pallet by leaving out inherited traits+2. Including only the required `Event` type++```rust,ignore+/// The pallet's configuration trait.+pub trait Trait: system::Trait { // Use traits here to tightly couple to runtime+    /// The overarching event type.+    type Event: From<Event<Self>> + Into<<Self as system::Trait>::Event>;+}+```++Later in the code, we implement some helper functions on this trait. The function bodies are+omitted for brevity's sake.++```rust,ignore+impl<T: Trait> Module<T> {+    // "Sends" a request to the local IPFS node by adding it to the offchain storage+    fn ipfs_request(req: IpfsRequest, deadline: impl Into<Option<Timestamp>>)+      -> Result<IpfsResponse, Error<T>>++    // Reads from the `ConnectionQueue` and connects / disconnects+    // from desired / undesired peers, respectively+    fn connection_housekeeping() -> Result<(), Error<T>>++    // Reads `FindPeer` and `GetProviders` commands from the `DhtQueue`,+    // and requests their execution from the native runtime+    fn handle_dht_requests() -> Result<(), Error<T>>++    // Reads `AddBytes`, `CatBytes`, `DataCommand`, `RemoveBlock`, `InsertPin`,+    // and `RemovePin` commands from the `DataQueue` and requests their+    // execution from the native runtime.+    fn handle_data_requests() -> Result<(), Error<T>>++    // Logs metadata (the number of connected peers) to the console at the DEBUG log level+    fn print_metadata() -> Result<(), Error<T>>+```++## The `decl_` macros++Pallets included in Substrate runtimes must adhere to the conventions of [FRAME].+In practice, this means you must implement `decl_` macros:++- `decl_module!`+- `decl_event!`+- `decl_storage!`+- `decl_error!`++[FRAME]: https://substrate.dev/docs/en/knowledgebase/runtime/frame+++### `decl_storage!`++Here, we define the data that will actually be stored on-chain as **extrinsics**.++Since the offchain-worker can't perform I/O outside of the wasm context, we store our requests as+queues, to be processed on a periodic basis, consumed, and ultimately performed by the native+runtime.++This is where we use the `ConnectionQueue`, `DataQueue`, and `DhtQueue` command types from above.++```rust,ignore+// This pallet's storage items.+decl_storage! {+    trait Store for Module<T: Trait> as TemplateModule {+        // A list of addresses to connect to and disconnect from.+        pub ConnectionQueue: Vec<ConnectionCommand>;+        // A queue of data to publish or obtain on IPFS.+        pub DataQueue: Vec<DataCommand>;+        // A list of requests to the DHT.+        pub DhtQueue: Vec<DhtCommand>;+    }+}+```++### `decl_event!`++This is where we define what those events are, when they happen, and what they contain.
This is where we define what those events are, and what they contain.

the call sites determine when they occur

aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as
expressed as `___Command` enums and stored in the offchain worker storage as

for consistence with the rest of the content

aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as+a queue, to be ingested by your native runtime and passed to IPFS.++Derive attributes are omitted.++```rust,ignore+// Commands involved in peer-to-peer connections+enum ConnectionCommand {+    ConnectTo(OpaqueMultiaddr),+    DisconnectFrom(OpaqueMultiaddr),+}++// Commands that add, remove, pin, unpin, and output data+enum DataCommand {+    AddBytes(Vec<u8>),+    CatBytes(Vec<u8>),+    InsertPin(Vec<u8>),+    RemoveBlock(Vec<u8>),+    RemovePin(Vec<u8>),+}++// Commands that query the distributed hash table (DHT)+// for peers and content+enum DhtCommand {+    FindPeer(Vec<u8>),+    GetProviders(Vec<u8>),+}+```++## The runtime configuration trait++The `system::Trait` trait (not to be confused with the Rust `trait` keyword), allows you to define+which capabilities from the runtime you want to include, and how you want to use them. You can also+"tightly couple" your pallet to other pallets by adding their `Trait`s to your pallet's+inherited trait list.++Here, however, we keep things simple by:++1. Loosely coupling this pallet by leaving out inherited traits+2. Including only the required `Event` type++```rust,ignore+/// The pallet's configuration trait.+pub trait Trait: system::Trait { // Use traits here to tightly couple to runtime+    /// The overarching event type.+    type Event: From<Event<Self>> + Into<<Self as system::Trait>::Event>;+}+```++Later in the code, we implement some helper functions on this trait. The function bodies are+omitted for brevity's sake.++```rust,ignore+impl<T: Trait> Module<T> {+    // "Sends" a request to the local IPFS node by adding it to the offchain storage+    fn ipfs_request(req: IpfsRequest, deadline: impl Into<Option<Timestamp>>)+      -> Result<IpfsResponse, Error<T>>++    // Reads from the `ConnectionQueue` and connects / disconnects+    // from desired / undesired peers, respectively+    fn connection_housekeeping() -> Result<(), Error<T>>++    // Reads `FindPeer` and `GetProviders` commands from the `DhtQueue`,+    // and requests their execution from the native runtime+    fn handle_dht_requests() -> Result<(), Error<T>>++    // Reads `AddBytes`, `CatBytes`, `DataCommand`, `RemoveBlock`, `InsertPin`,+    // and `RemovePin` commands from the `DataQueue` and requests their+    // execution from the native runtime.+    fn handle_data_requests() -> Result<(), Error<T>>++    // Logs metadata (the number of connected peers) to the console at the DEBUG log level+    fn print_metadata() -> Result<(), Error<T>>+```++## The `decl_` macros++Pallets included in Substrate runtimes must adhere to the conventions of [FRAME].+In practice, this means you must implement `decl_` macros:++- `decl_module!`+- `decl_event!`+- `decl_storage!`+- `decl_error!`++[FRAME]: https://substrate.dev/docs/en/knowledgebase/runtime/frame+++### `decl_storage!`++Here, we define the data that will actually be stored on-chain as **extrinsics**.
Here, we define the data that will actually be stored on-chain when calling **extrinsics**.
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

+# Example Pallet++`offchain::ipfs` comes with a showcase **[pallet]**, which is essentially a Rust module that+complies with the requirements to be included within a substrate **runtime**.++> **This pallet is meant only as an example.** We're including it to be helpful for future pallet authors+that want to use the embedded native IPFS node to suit their needs.++If you're familiar with Substrate and the Framework for Runtime Aggregation of Modularized Entities+(FRAME), you can simply view the [source code] for this pallet. Otherwise, read on as we go through+the code step by step.++Please note the order in which these concepts are explained here is not necessarily the order that+they appear in the code.++You can also learn more by following the [Building a Custom Pallet] tutorial.++[Building a Custom Pallet]: https://substrate.dev/docs/en/tutorials/build-a-dapp/pallet+[source code]: https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/pallets/template/src/lib.rs+[pallet]: https://substrate.dev/docs/en/knowledgebase/runtime/pallets++## Prelude++We start by using items from the native runtime. Our pallet is `no_std` since we're targeting `Wasm`++```rust,ignore+#![cfg_attr(not(feature = "std"), no_std)]+// ...+use sp_core::offchain::{+  Duration, IpfsRequest, IpfsResponse, OpaqueMultiaddr, Timestamp+};+// ...+use sp_runtime::offchain::ipfs;+```++## Command Types++When your JSON-RPC calls are received by the pallet, the requests are+expressed as `___Command` enums and stored in the off-chain worker storage as+a queue, to be ingested by your native runtime and passed to IPFS.++Derive attributes are omitted.++```rust,ignore+// Commands involved in peer-to-peer connections+enum ConnectionCommand {+    ConnectTo(OpaqueMultiaddr),+    DisconnectFrom(OpaqueMultiaddr),+}++// Commands that add, remove, pin, unpin, and output data+enum DataCommand {+    AddBytes(Vec<u8>),+    CatBytes(Vec<u8>),+    InsertPin(Vec<u8>),+    RemoveBlock(Vec<u8>),+    RemovePin(Vec<u8>),+}++// Commands that query the distributed hash table (DHT)+// for peers and content+enum DhtCommand {+    FindPeer(Vec<u8>),+    GetProviders(Vec<u8>),+}+```++## The runtime configuration trait++The `system::Trait` trait (not to be confused with the Rust `trait` keyword), allows you to define+which capabilities from the runtime you want to include, and how you want to use them. You can also+"tightly couple" your pallet to other pallets by adding their `Trait`s to your pallet's+inherited trait list.++Here, however, we keep things simple by:++1. Loosely coupling this pallet by leaving out inherited traits+2. Including only the required `Event` type++```rust,ignore+/// The pallet's configuration trait.+pub trait Trait: system::Trait { // Use traits here to tightly couple to runtime+    /// The overarching event type.+    type Event: From<Event<Self>> + Into<<Self as system::Trait>::Event>;+}+```++Later in the code, we implement some helper functions on this trait. The function bodies are+omitted for brevity's sake.++```rust,ignore+impl<T: Trait> Module<T> {+    // "Sends" a request to the local IPFS node by adding it to the offchain storage+    fn ipfs_request(req: IpfsRequest, deadline: impl Into<Option<Timestamp>>)+      -> Result<IpfsResponse, Error<T>>++    // Reads from the `ConnectionQueue` and connects / disconnects+    // from desired / undesired peers, respectively+    fn connection_housekeeping() -> Result<(), Error<T>>++    // Reads `FindPeer` and `GetProviders` commands from the `DhtQueue`,+    // and requests their execution from the native runtime+    fn handle_dht_requests() -> Result<(), Error<T>>++    // Reads `AddBytes`, `CatBytes`, `DataCommand`, `RemoveBlock`, `InsertPin`,+    // and `RemovePin` commands from the `DataQueue` and requests their+    // execution from the native runtime.+    fn handle_data_requests() -> Result<(), Error<T>>++    // Logs metadata (the number of connected peers) to the console at the DEBUG log level+    fn print_metadata() -> Result<(), Error<T>>+```++## The `decl_` macros++Pallets included in Substrate runtimes must adhere to the conventions of [FRAME].+In practice, this means you must implement `decl_` macros:++- `decl_module!`+- `decl_event!`+- `decl_storage!`+- `decl_error!`++[FRAME]: https://substrate.dev/docs/en/knowledgebase/runtime/frame+
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.++Finally, while we list "return" values for simplicity's sake, the template pallet does not actually+return any values from the RPC calls. What this really means in the context of Substrate is that the+values will be _eventually_ emitted returned in the runtime logs, which you'll need to monitor.++### `ipfs_add_bytes`++Adds the given bytes to the IPFS repository++**Frequency:** Every other block<br />+**Weight**: 200,000<br />++#### Arguments++- `bytes` - `Vec<u8>`, e.g. `vec![1, 2, 3, 4]` or `b"1234"`++#### Returns++A Content ID (CID) string, e.g. `QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa`++### `ipfs_cat_bytes`++Displays the bytes behind a given CID
Displays the bytes behind a given CID.
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.++Finally, while we list "return" values for simplicity's sake, the template pallet does not actually+return any values from the RPC calls. What this really means in the context of Substrate is that the+values will be _eventually_ emitted returned in the runtime logs, which you'll need to monitor.++### `ipfs_add_bytes`++Adds the given bytes to the IPFS repository
Adds the given bytes to the IPFS repository.
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.++Finally, while we list "return" values for simplicity's sake, the template pallet does not actually+return any values from the RPC calls. What this really means in the context of Substrate is that the+values will be _eventually_ emitted returned in the runtime logs, which you'll need to monitor.++### `ipfs_add_bytes`++Adds the given bytes to the IPFS repository++**Frequency:** Every other block<br />+**Weight**: 200,000<br />++#### Arguments++- `bytes` - `Vec<u8>`, e.g. `vec![1, 2, 3, 4]` or `b"1234"`++#### Returns++A Content ID (CID) string, e.g. `QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa`++### `ipfs_cat_bytes`++Displays the bytes behind a given CID++**Frequency:** Every other block<br />+**Weight**: 100,000++#### Arguments++- `cid`: A `Vec<u8>` CID, e.g. `b"QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa"`++#### Returns++The requested bytes - UTF-8 as a string, non-UTF-8 as hexidecimal string++### `ipfs_connect`++Connects the embedded node to the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++Nothing, or an error.++### `ipfs_disconnect`++Disconnects from the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 500,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++Nothing, or an error.++### `ipfs_dht_findpeer`++Performs a search for the addresses associated with the provided PeerId.++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `peerID`: A `PeerId` string, e.g. `QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++An "opaque" multiaddr, i.e. one without a `PeerId`, such as `/ip4/104.131.131.82/tcp/4001`.++### `ipfs_dht_findproviders`++Search for PeerIds known to be providing the given Cid. You must connected to at least one peer!
Search for PeerIds known to be providing the given Cid. You must have been connected to at least one peer!
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.++Finally, while we list "return" values for simplicity's sake, the template pallet does not actually+return any values from the RPC calls. What this really means in the context of Substrate is that the+values will be _eventually_ emitted returned in the runtime logs, which you'll need to monitor.++### `ipfs_add_bytes`++Adds the given bytes to the IPFS repository++**Frequency:** Every other block<br />+**Weight**: 200,000<br />++#### Arguments++- `bytes` - `Vec<u8>`, e.g. `vec![1, 2, 3, 4]` or `b"1234"`++#### Returns++A Content ID (CID) string, e.g. `QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa`++### `ipfs_cat_bytes`++Displays the bytes behind a given CID++**Frequency:** Every other block<br />+**Weight**: 100,000++#### Arguments++- `cid`: A `Vec<u8>` CID, e.g. `b"QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa"`++#### Returns++The requested bytes - UTF-8 as a string, non-UTF-8 as hexidecimal string++### `ipfs_connect`++Connects the embedded node to the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++Nothing, or an error.++### `ipfs_disconnect`++Disconnects from the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 500,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++Nothing, or an error.++### `ipfs_dht_findpeer`++Performs a search for the addresses associated with the provided PeerId.++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `peerID`: A `PeerId` string, e.g. `QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++An "opaque" multiaddr, i.e. one without a `PeerId`, such as `/ip4/104.131.131.82/tcp/4001`.++### `ipfs_dht_findproviders`++Search for PeerIds known to be providing the given Cid. You must connected to at least one peer!++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `cid`: The CID string of your desired content, e.g. `QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU`++#### Returns++- `peerID`: An array `PeerId` string, e.g. `[QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ]`++### `ipfs_insert_pin`++Non-recursively pins a block with the specified Cid, protecting it from removal.++**Frequency:** Every other block<br />+**Weight**: 100,000++#### Arguments++- `cid`: The CID string data you want to pin, e.g. `QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa`++#### Returns++Nothing, or an error.++### `ipfs_remove_pin`++Removes a pin from a block, so that it is no longer persistent and can be removed.++**Frequency:** Every other block<br />+**Weight**: 100,000++#### Arguments++- `cid`: The CID string data you want to unpin, e.g. `QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa`++#### Returns++### `ipfs_remove_block`++Removes a block from the node’s repository
Removes a block from the node’s repository.
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.++Finally, while we list "return" values for simplicity's sake, the template pallet does not actually+return any values from the RPC calls. What this really means in the context of Substrate is that the+values will be _eventually_ emitted returned in the runtime logs, which you'll need to monitor.++### `ipfs_add_bytes`++Adds the given bytes to the IPFS repository++**Frequency:** Every other block<br />+**Weight**: 200,000<br />++#### Arguments++- `bytes` - `Vec<u8>`, e.g. `vec![1, 2, 3, 4]` or `b"1234"`++#### Returns++A Content ID (CID) string, e.g. `QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa`++### `ipfs_cat_bytes`++Displays the bytes behind a given CID++**Frequency:** Every other block<br />+**Weight**: 100,000++#### Arguments++- `cid`: A `Vec<u8>` CID, e.g. `b"QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa"`++#### Returns++The requested bytes - UTF-8 as a string, non-UTF-8 as hexidecimal string++### `ipfs_connect`++Connects the embedded node to the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`
- `multiaddr`: A `Vec<u8>`, e.g. `b"/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ".to_vec()`

all the native Rust arguments in the example pallets are Vec<u8>

aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.++Finally, while we list "return" values for simplicity's sake, the template pallet does not actually+return any values from the RPC calls. What this really means in the context of Substrate is that the+values will be _eventually_ emitted returned in the runtime logs, which you'll need to monitor.++### `ipfs_add_bytes`++Adds the given bytes to the IPFS repository++**Frequency:** Every other block<br />+**Weight**: 200,000<br />++#### Arguments++- `bytes` - `Vec<u8>`, e.g. `vec![1, 2, 3, 4]` or `b"1234"`++#### Returns++A Content ID (CID) string, e.g. `QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa`++### `ipfs_cat_bytes`++Displays the bytes behind a given CID++**Frequency:** Every other block<br />+**Weight**: 100,000++#### Arguments++- `cid`: A `Vec<u8>` CID, e.g. `b"QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa"`++#### Returns++The requested bytes - UTF-8 as a string, non-UTF-8 as hexidecimal string++### `ipfs_connect`++Connects the embedded node to the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++Nothing, or an error.++### `ipfs_disconnect`++Disconnects from the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 500,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++Nothing, or an error.++### `ipfs_dht_findpeer`++Performs a search for the addresses associated with the provided PeerId.++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `peerID`: A `PeerId` string, e.g. `QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++An "opaque" multiaddr, i.e. one without a `PeerId`, such as `/ip4/104.131.131.82/tcp/4001`.
A multiaddr, such as `/ip4/104.131.131.82/tcp/4001`.

OpaqueMultiaddr doesn't necessarily mean there is no PeerId - it was just an alias already exposed by substrate

aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.++Finally, while we list "return" values for simplicity's sake, the template pallet does not actually+return any values from the RPC calls. What this really means in the context of Substrate is that the+values will be _eventually_ emitted returned in the runtime logs, which you'll need to monitor.++### `ipfs_add_bytes`++Adds the given bytes to the IPFS repository++**Frequency:** Every other block<br />+**Weight**: 200,000<br />++#### Arguments++- `bytes` - `Vec<u8>`, e.g. `vec![1, 2, 3, 4]` or `b"1234"`++#### Returns++A Content ID (CID) string, e.g. `QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa`++### `ipfs_cat_bytes`++Displays the bytes behind a given CID++**Frequency:** Every other block<br />+**Weight**: 100,000++#### Arguments++- `cid`: A `Vec<u8>` CID, e.g. `b"QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa"`++#### Returns++The requested bytes - UTF-8 as a string, non-UTF-8 as hexidecimal string++### `ipfs_connect`++Connects the embedded node to the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++Nothing, or an error.++### `ipfs_disconnect`++Disconnects from the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 500,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++Nothing, or an error.++### `ipfs_dht_findpeer`++Performs a search for the addresses associated with the provided PeerId.++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `peerID`: A `PeerId` string, e.g. `QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`

ditto

aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.++Finally, while we list "return" values for simplicity's sake, the template pallet does not actually+return any values from the RPC calls. What this really means in the context of Substrate is that the+values will be _eventually_ emitted returned in the runtime logs, which you'll need to monitor.++### `ipfs_add_bytes`++Adds the given bytes to the IPFS repository++**Frequency:** Every other block<br />+**Weight**: 200,000<br />++#### Arguments++- `bytes` - `Vec<u8>`, e.g. `vec![1, 2, 3, 4]` or `b"1234"`
- `bytes` - `Vec<u8>`, e.g. `vec![1, 2, 3, 4]` or `b"1234".to_vec()`

the latter was not a Rust vector, but a byte array literal

aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.++Finally, while we list "return" values for simplicity's sake, the template pallet does not actually+return any values from the RPC calls. What this really means in the context of Substrate is that the+values will be _eventually_ emitted returned in the runtime logs, which you'll need to monitor.++### `ipfs_add_bytes`++Adds the given bytes to the IPFS repository++**Frequency:** Every other block<br />+**Weight**: 200,000<br />++#### Arguments++- `bytes` - `Vec<u8>`, e.g. `vec![1, 2, 3, 4]` or `b"1234"`++#### Returns++A Content ID (CID) string, e.g. `QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa`++### `ipfs_cat_bytes`++Displays the bytes behind a given CID++**Frequency:** Every other block<br />+**Weight**: 100,000++#### Arguments++- `cid`: A `Vec<u8>` CID, e.g. `b"QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa"`++#### Returns++The requested bytes - UTF-8 as a string, non-UTF-8 as hexidecimal string++### `ipfs_connect`++Connects the embedded node to the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 100,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`++#### Returns++Nothing, or an error.++### `ipfs_disconnect`++Disconnects from the given Multiaddr.++**Frequency:** Every block<br />+**Weight**: 500,000++#### Arguments++- `multiaddr`: A string, e.g. `/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ`

ditto

aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.++Finally, while we list "return" values for simplicity's sake, the template pallet does not actually+return any values from the RPC calls. What this really means in the context of Substrate is that the+values will be _eventually_ emitted returned in the runtime logs, which you'll need to monitor.++### `ipfs_add_bytes`++Adds the given bytes to the IPFS repository++**Frequency:** Every other block<br />+**Weight**: 200,000<br />++#### Arguments++- `bytes` - `Vec<u8>`, e.g. `vec![1, 2, 3, 4]` or `b"1234"`++#### Returns++A Content ID (CID) string, e.g. `QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa`++### `ipfs_cat_bytes`++Displays the bytes behind a given CID++**Frequency:** Every other block<br />+**Weight**: 100,000++#### Arguments++- `cid`: A `Vec<u8>` CID, e.g. `b"QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa"`
- `cid`: A `Vec<u8>` containing a CID, e.g. `b"QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa".to_vec()`
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at+[rs-ipfs/substrate].++[rs-ipfs/substrate]: https://github.com/rs-ipfs/substrate++## Callables++What follows is a list of callables, their frequency in terms of block creation, their weights,+their arguments and return values. As explained in the previous section on the example pallet,+weights are essentially picosecond representations of a time limit for a given transaction,+and can be loosely correlated to transaction fees.++> **Rust's `snake_case` is used here.** However, as you'll see in the upcoming polkadot.js example,+JavaScript will use `camelCase` for function and variable names. Generally, the exposed JSON-RPC+functions will adhere to the conventions of the programming language that the client code is+written in.++Also, the weights here and block frequencies here are chosen rather arbitrarily without tokenomics+in mind. You will need to tune these values in your own custom pallet.
in mind. You will probably need to tune these values in your own custom pallet.
aphelionz

comment created time in 7 days

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions+available in the native runtime, and therefore do not represent the full extent of functionality+available to you.++Regardless, we still detail the example template functions here as a helpful reference. If you have+feedback about these existing functions, or would like to request new functions, please open an issue at
feedback about these existing functions, or would like to request new ones, please open an issue at
aphelionz

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# offchain::ipfs callables--The following callables are available to you. These were chosen due to popularity and to try-and give substrate uses the most cohesive and familiar experience using IPFS within their node.--- api.tx.templateModule.ipfsAddBytes - add the given bytes to the IPFS repository; the off-chain worker interval for this activity is every block with an odd BlockNumber (i.e. every other block). For example adding 1234 gives you the CID QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsCatBytes - display the bytes (UTF-8 is displayed as a string, while non-UTF-8 bytes are displayed in their hexadecimal representation) with the given Cid; the off-chain worker interval for this activity is also every block with an odd BlockNumber. In the inverse of the last item, requesting the CID above will return 1234-- api.tx.templateModule.ipfsConnect - connect to the given Multiaddr; the off-chain worker interval for this activity is every block (the queue of connection requests is processed with every block in the chain). Try it with /ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.-- api.tx.templateModule.ipfsDisconnect - disconnect from the given Multiaddr; the off-chain worker interval for this activity is also every block. You can try disconnecting from multiaddr from the previous item.-- api.tx.templateModule.ipfsDhtFindPeer - perform a search for the addresses associated with the provided PeerId; the off-chain worker interval for this activity is every block. If you use the peerID from two items prior, QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ, it will return /ip4/104.131.131.82/tcp/4001.-- api.tx.templateModule.ipfsDhtFindProviders - search for PeerIds known to be providing the given Cid; the off-chain worker interval for this activity is every block. Try it with the hash of the IPFS CID Inspector, QmY7Yh4UquoXHLPFo2XbhXkhBvFoPwmQUSa92pxnxjQuPU. Make sure you’re connected to at least one peer though!-- api.tx.templateModule.ipfsInsertPin - pin a block with the specified Cid, making it persistent; a pinned block can’t be removed. Try pinning the 1234 CID above: QmU1f6ngsoHvwtViihzLQPXCA8j3sagmvY9GJJDY7Ao7Aa-- api.tx.templateModule.ipfsRemovePin - remove a pin from a block, i.e. unpin it, so that it is no longer persistent and can be removed too. Trey removing the pin from the previous item.-- api.tx.templateModule.ipfsRemoveBlock - remove a block from the node’s repository+# Example pallet callable reference++The following callable functions are exposed via JSON-RPC by the example pallet.+These specific functions were chosen due to popularity, to give you a familiar experience.++However, as we explain at the bottom of this page, these functions are not the only functions
However, as we explain at the bottom of this page, these functions are not the only ones
aphelionz

comment created time in 7 days

PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# Building an offchain::ipfs app+# Building an `offchain::ipfs` app -In this book we’ll cover the bare essentials on what you need to start building out your dApp-with offchain::ipfs. We cover two Rust clients and one JavaScript client, but there are-many other clients in other languages.+In this section we’ll cover the essentials on what you'll need to start building your+application with `offchain::ipfs`. We do so by way of an example.++1. First, we walk you through the example Substrate pallet that's included with `offchain::ipfs`+2. Then, we provide example code from two Rust clients (`substrate-subxt` and+`substrat-api-client`), and one JavaScript client (`polkadot.js`) as they relate++We expect feedback on this pallet, but also we hope that the reference implementation will inspire+builders to create their own pallets, expose their own JSON-RPC endpoints, and call them from+their applications similarly.++## How it all works++It helps, first, to have a basic understanding of how a request flows from a user of your+application, through the Substrate offchain-worker, to the native runtime, over to IPFS,+and then all the way back up to your application again.++1. Once the chain is initialized or blocks are synced, the embedded Rust IPFS+node is launched and connected to the offchain worker runtime. It will stay running+in the background.+2. The user makes JSON-RPC call to submit an extrinsic to the node's runtime, using+the callable functions exposed from the custom pallet.+3. The requests is added to the relevant queue in the Substrate storage database.+This is also defined in the custom pallet.+4. On block import the node's runtime passes some requests from the queues to a+new offchain worker.+5. The request offchain worker performs future requests to the Rust IPFS node, and+the returned results resolve the futures+6. The request offchain worker registers the result in its API the the node's+runtime, which reads it and emits events declared in the custom pallet.+7. The request offchain worker stops running
7. The offchain worker stops running
aphelionz

comment created time in 7 days

PullRequestReviewEvent

Pull request review commentrs-ipfs/offchain-ipfs-manual

Building an offchain::ipfs app

-# Building an offchain::ipfs app+# Building an `offchain::ipfs` app -In this book we’ll cover the bare essentials on what you need to start building out your dApp-with offchain::ipfs. We cover two Rust clients and one JavaScript client, but there are-many other clients in other languages.+In this section we’ll cover the essentials on what you'll need to start building your+application with `offchain::ipfs`. We do so by way of an example.++1. First, we walk you through the example Substrate pallet that's included with `offchain::ipfs`+2. Then, we provide example code from two Rust clients (`substrate-subxt` and+`substrat-api-client`), and one JavaScript client (`polkadot.js`) as they relate++We expect feedback on this pallet, but also we hope that the reference implementation will inspire+builders to create their own pallets, expose their own JSON-RPC endpoints, and call them from+their applications similarly.++## How it all works++It helps, first, to have a basic understanding of how a request flows from a user of your+application, through the Substrate offchain-worker, to the native runtime, over to IPFS,+and then all the way back up to your application again.++1. Once the chain is initialized or blocks are synced, the embedded Rust IPFS+node is launched and connected to the offchain worker runtime. It will stay running+in the background.+2. The user makes JSON-RPC call to submit an extrinsic to the node's runtime, using+the callable functions exposed from the custom pallet.+3. The requests is added to the relevant queue in the Substrate storage database.+This is also defined in the custom pallet.+4. On block import the node's runtime passes some requests from the queues to a+new offchain worker.+5. The request offchain worker performs future requests to the Rust IPFS node, and+the returned results resolve the futures+6. The request offchain worker registers the result in its API the the node's+runtime, which reads it and emits events declared in the custom pallet.
runtime, which processes them and acts upon them as declared in the custom pallet.
aphelionz

comment created time in 7 days

more