Coder Social home page Coder Social logo

dappforce / subsocial-solochain Goto Github PK

View Code? Open in Web Editor NEW

This project forked from substrate-developer-hub/substrate-node-template

81.0 8.0 22.0 62.89 MB

NOTE: Development continues in https://github.com/dappforce/subsocial-parachain repo. Subsocial full node with Substrate/Polkadot pallets for decentralized communities: blogs, posts, comments, likes, reputation.

Home Page: http://subsocial.network

License: GNU General Public License v3.0

Shell 0.53% Rust 98.29% Dockerfile 0.16% JavaScript 0.25% HTML 0.01% Handlebars 0.76%
polkadot substrate blockchain dapp social-network blog-platform blog-engine comment-system commenting decentralized decentralized-application activity-feed activity-stream news-feed medium-clone reddit-clone twitter-clone subsocial dappforce social-media

subsocial-solochain's Introduction

Note: Development continues in subsocial-parachain repo.

Subsocial Node by DappForce

Subsocial is a set of Substrate pallets with web UI that allows anyone to launch their own decentralized censorship-resistant social network aka community. Every community can be a separate Substrate chain and connect with other communities via a Polkadot-based relay chain.

You can think of this as decentralized versions of Reddit, Stack Exchange or Medium, where subreddits or communities of Stack Exchange or blogs on Medium run on their own chain. At the same time, users of these decentralized communities should be able to share their reputation or transfer coins and other values from one community to another via Polkadot relay chain.

To learn more about Subsocial, please visit Subsocial Network.

Build

Build from scratch

Install Rust:

curl https://sh.rustup.rs -sSf | sh

Initialize your Wasm Build environment:

./scripts/init.sh

Build Wasm and native code:

cargo build --release

Build runtime WASM with SRTool

You need to have docker installed for this type of build.

Add SRTool alias:

export RUSTC_VERSION=nightly-2021-03-15; export PACKAGE=subsocial-runtime; alias srtool='docker run --rm -it -e RUNTIME_DIR=runtime -e PACKAGE=$PACKAGE -v $PWD:/build -v "$TMPDIR"/cargo:/cargo-home chevdor/srtool:$RUSTC_VERSION'

Run build:

srtool build

Run

Single Node Development Chain

Purge any existing developer chain state:

./target/release/subsocial-node purge-chain --dev

Start a development chain with:

./target/release/subsocial-node --dev

Detailed logs may be shown by running the node with the following environment variables set: RUST_LOG=debug RUST_BACKTRACE=1 cargo run -- --dev.

Multi-Node Local Testnet

If you want to see the multi-node consensus algorithm in action locally, then you can create a local testnet with two validator nodes for Alice and Bob, who are the initial authorities of the genesis chain that have been endowed with testnet units.

Optionally, give each node a name and expose them so they are listed on the Polkadot telemetry site.

You'll need two terminal windows open.

We'll start Alice's substrate node first on default TCP port 30333 with her chain database stored locally at /tmp/alice. The bootnode ID of her node is QmRpheLN4JWdAnY7HGJfWFNbfkQCb6tFf4vvA6hgjMZKrR, which is generated from the --node-key value that we specify below:

cargo run -- \
  --base-path /tmp/alice \
  --chain=local \
  --alice \
  --node-key 0000000000000000000000000000000000000000000000000000000000000001 \
  --telemetry-url ws://telemetry.polkadot.io:1024 \
  --validator

In the second terminal, we'll start Bob's substrate node on a different TCP port of 30334, and with his chain database stored locally at /tmp/bob. We'll specify a value for the --bootnodes option that will connect his node to Alice's bootnode ID on TCP port 30333:

cargo run -- \
  --base-path /tmp/bob \
  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/QmRpheLN4JWdAnY7HGJfWFNbfkQCb6tFf4vvA6hgjMZKrR \
  --chain=local \
  --bob \
  --port 30334 \
  --telemetry-url ws://telemetry.polkadot.io:1024 \
  --validator

Additional CLI usage options are available and may be shown by running cargo run -- --help.

License

Subsocial is GPL 3.0 licensed.

subsocial-solochain's People

Contributors

f3joule avatar joshorndorff avatar olehmell avatar riusricardo avatar samchuk-vlad avatar shawntabrizi avatar siman avatar subsocialdev avatar tarekkma avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

subsocial-solochain's Issues

Compiling on Apple M1

I cannot compile subsocial-node and I believe it might be related to this issue.

not sure how to proceed, to be honest so any help is appreciated.

add rust version info for build

hi,
Initialize Wasm Build environment

./scripts/init.sh

then build

cargo build --release

will get error

add specified version at rust-toolchain file maybe a good choice.

I solve the compilation problem by specifying the version.

rustup install nightly-2020-06-27
rustup target add wasm32-unknown-unknown --toolchain nightly-2020-06-27

then build

cargo build --release

Can not transfer SUB successfully: Bad Origin

I submit SUB transaction to the node, it has no error, but When I search it on chain , found it failed DispatchError BadOrigin, is SUB can transfer now? Or is there something wrong with my transaction body? How can I solve it? thanks a lot

Do not lowercase a blog handle

Do not lowercase a blog handle when storing it in a Blog struct. Lowercase only for storage item where we store a map of unique handles to resolve blog id.

Error when build code

after launch
cargo build --release
appear the error:

Compiling frame-support v2.0.0-rc4 (https://github.com/paritytech/substrate.git?tag=v2.0.0-rc4#00768a1f)
error[E0424]: expected value, found module self
--> /root/.cargo/git/checkouts/substrate-7e08433d4c370a21/00768a1/frame/support/src/traits.rs:1172:11
|
1170 | / bitmask! {
1171 | | /// Reasons for moving funds out of an account.
1172 | | #[derive(Encode, Decode)]
| | ^^^^^^ self value is a keyword only available in methods with a self parameter
1173 | | pub mask WithdrawReasons: i8 where
... |
1188 | | }
1189 | | }
| |_- this function has a self parameter, but a macro invocation can only access identifiers it receives from parameters
|
= note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to previous error

For more information about this error, try rustc --explain E0424.
error: could not compile frame-support.

Move most of storage items that return Vec-s to offchain worker DB

We have around 10 storage items that return Vec of ids, like replyIdsByPostIds. These vecs are not used in runtime logic and mostly consumed by the clients (for example Subsocial's UI).

By moving them to offchain we will speedup a read-time from DB and save the blockchain storage space.

By offchain DB, I mean the high performance key-value DB that is available to Substrate's offchain worker.

can not sync block at 6600871

no other detail log for info level, just like following:

Nov 13 22:12:22 node3-SG subsocial-node[193229]: 2021-11-13 22:12:22.486   INFO tokio-runtime-worker substrate: 💤 Idle (4 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 1.1kiB/s ⬆ 1.2kiB/s
Nov 13 22:12:27 node3-SG subsocial-node[193229]: 2021-11-13 22:12:27.486   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 1.2kiB/s ⬆ 1.2kiB/s
Nov 13 22:12:32 node3-SG subsocial-node[193229]: 2021-11-13 22:12:32.486   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 1.8kiB/s ⬆ 2.1kiB/s
Nov 13 22:12:37 node3-SG subsocial-node[193229]: 2021-11-13 22:12:37.486   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 2.9kiB/s ⬆ 1.5kiB/s
Nov 13 22:12:42 node3-SG subsocial-node[193229]: 2021-11-13 22:12:42.486   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 1.5kiB/s ⬆ 1.8kiB/s
Nov 13 22:12:47 node3-SG subsocial-node[193229]: 2021-11-13 22:12:47.486   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 1.1kiB/s ⬆ 1.8kiB/s
Nov 13 22:12:52 node3-SG subsocial-node[193229]: 2021-11-13 22:12:52.486   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 1.6kiB/s ⬆ 1.7kiB/s
Nov 13 22:12:57 node3-SG subsocial-node[193229]: 2021-11-13 22:12:57.486   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 1.3kiB/s ⬆ 1.5kiB/s
Nov 13 22:13:02 node3-SG subsocial-node[193229]: 2021-11-13 22:13:02.486   INFO tokio-runtime-worker substrate: ⚙️  Syncing  0.0 bps, target=#6611542 (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 1.0kiB/s ⬆ 1.2kiB/s
Nov 13 22:13:07 node3-SG subsocial-node[193229]: 2021-11-13 22:13:07.486   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 4.2kiB/s ⬆ 53.4kiB/s
Nov 13 22:13:12 node3-SG subsocial-node[193229]: 2021-11-13 22:13:12.486   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 57.8kiB/s ⬆ 52.6kiB/s
Nov 13 22:13:17 node3-SG subsocial-node[193229]: 2021-11-13 22:13:17.487   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 59.4kiB/s ⬆ 53.1kiB/s
Nov 13 22:13:22 node3-SG subsocial-node[193229]: 2021-11-13 22:13:22.487   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 60.1kiB/s ⬆ 22.0kiB/s
Nov 13 22:13:27 node3-SG subsocial-node[193229]: 2021-11-13 22:13:27.487   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 1.7kiB/s ⬆ 2.0kiB/s
Nov 13 22:13:32 node3-SG subsocial-node[193229]: 2021-11-13 22:13:32.487   INFO tokio-runtime-worker substrate: 💤 Idle (3 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 0.8kiB/s ⬆ 1.1kiB/s
Nov 13 22:13:37 node3-SG subsocial-node[193229]: 2021-11-13 22:13:37.487   INFO tokio-runtime-worker substrate: 💤 Idle (4 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 3.1kiB/s ⬆ 2.5kiB/s
Nov 13 22:13:42 node3-SG subsocial-node[193229]: 2021-11-13 22:13:42.487   INFO tokio-runtime-worker substrate: 💤 Idle (4 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 0.8kiB/s ⬆ 176.0kiB/s
Nov 13 22:13:47 node3-SG subsocial-node[193229]: 2021-11-13 22:13:47.487   INFO tokio-runtime-worker substrate: 💤 Idle (4 peers), best: #6600871 (0xaa1c…f582), finalized #6600871 (0xaa1c…f582), ⬇ 2.0kiB/s ⬆ 2.1kiB/s

node version: subsocial-node 0.7.0-5c62197-x86_64-linux-gnu

Move edit_history to off-chain worker

We should store an edit history in offchain.
Blogs and Posts should not accumulate edit history information.

Let's more this info to the local storage of offchain worker:
pub edit_history: Vec<BlogHistoryRecord<T>>

Create Roles pallet

Permissions pallet design

enum SpacePermission {

  /// Create, update, grant and revoke roles in this space.
  ManageRoles,
  /// Create, update own and delete any subspaces in this space.
  ManageSubspaces,
  /// Create, update own and delete any root posts in this space.
  ManagePosts,
  /// Create, update own and delete any comments in this space.
  ManageComments,

  /// Act on behalf of this space within this space.
  RepresentSpaceInternally,
  /// Act on behalf of this space outside of this space.
  RepresentSpaceExternally,

  UpdateSpace,
  BlockUsers, // or BlockActors

  // TODO what about 'DeleteSpace'? (too dangerous)

  // Related to subspaces in this space:
  CreateSubspaces,
  UpdateOwnSubspaces,
  DeleteOwnSubspaces,
  DeleteAnySubspaces,

  // Related to posts in this space:
  CreatePosts,
  UpdateOwnPosts,
  DeleteOwnPosts,
  DeleteAnyPosts,

  // Related to comments in this space:
  CreateComments,
  UpdateOwnComments,
  DeleteOwnComments,
  DeleteAnyComments,

  /// Upvote on any post or comment in this space.
  Upvote,
  /// Upvote on any post or comment in this space.
  Downvote,
  /// Share any post or comment from this space to another outer space.
  Share,
}

enum PostPermission {

  // Related to comments on this post:
  CreateComments,
  UpdateOwnComments,
  DeleteOwnComments,

  // Related to this post and its comments:
  Upvote,
  Downvote,
  Share,
}

Changes to Social pallet

We can add permissions overrides directly to Space and Post structs. We already load Space and root Post (if adding a comment) in the extrinsic create_post(). This means that if we have permissions overrides in the loaded Space and root Post then we don't need to do an extra read-request to Runtime storage – that is great performance optimization.

// NOTE: Currently it's called `Blog` struct.
struct Space {
  // ... previous fields go here ...

  /// Overrides the default permissions for everyone on this space.
  /// If `None` then this space does not override the default permissions for everyone. 
  pub everyonePermissions: Option<BTreeSet<SpacePermission>>,

  /// Overrides the default permissions for followers on this space.
  /// If `None` then this space does not override the default permissions for followers. 
  pub followerPermissions: Option<BTreeSet<SpacePermission>>,
}

struct Post {
  // ... previous fields go here ...

  /// Overrides the default permissions for everyone on this post and its comments.
  /// If `None` then this post does not override the default permissions for followers. 
  pub everyonePermissions: Option<BTreeSet<PostPermission>>,

  /// Overrides the default permissions for followers on this post and its comments.
  /// If `None` then this post does not override the default permissions for followers. 
  pub followerPermissions: Option<BTreeSet<PostPermission>>,
}

Roles pallet design

type RoleId = u64;

struct Role<T: Trait> {
  pub created: WhoAndWhen<T>,
  pub updated: Option<WhoAndWhen<T>>,
  pub id: RoleId,
  pub space_id: SpaceId,
  pub disabled: bool,
  pub ipfs_hash: Vec<u8>,
  pub permissions: BTreeSet<SpacePermission>,
}

pub struct RoleUpdate {
  pub disabled: Option<bool>,
  pub ipfs_hash: Option<Vec<u8>>,
  pub permissions: Option<BTreeSet<SpacePermission>>,
}

// TODO Move this helper enum to `utils` pallet.
// TODO Maybe this enum to 'User'?
enum Actor<AccountId> {
  Account(AccountId),
  Space(SpaceId)
}

decl_storage! {

  /// Get role details by ids id.
  RoleById: map RoleId => Option<Role<T>>;

  /// A list of all account ids and space ids that have this role.
  ActorsByRoleId: map RoleId => Vec<Actor>;

  /// A list of all role ids available in this space.
  RoleIdsBySpaceId: map SpaceId => Vec<RoleId>;

  /// A list of all role ids granted to this actor (either account of space) within this space.
  InSpaceRoleIdsByActor: double_map (Actor, SpaceId) => Vec<RoleId>;
}

// Extrinsics

/// Create a new role within this space with the list of particular permissions.
/// `ipfs_hash` points to the off-chain content with such role info as name, description, color.
/// Only the space owner or an actor with `ManageRoles` permission can execute this extrinsic.
pub fn create_role(origin, space_id: SpaceId, permissions: BTreeSet<SpacePermission>, ipfs_hash: Vec<u8>) {}

/// Update an existing role on specified space.
/// It is possible to either update permissions by overriding existing permissions,
/// or update IPFS hash or both.
/// Only the space owner or an actor with `ManageRoles` permission can execute this extrinsic.
pub fn update_role(origin, role_id: RoleId, update: RoleUpdate) {}

/// Delete the role from all associated storage items.
/// Only the space owner or an actor with `ManageRoles` permission can execute this extrinsic.
pub fn delete_role(origin, role_id: RoleId, update: RoleUpdate) {}

/// Grant the role from the list of actors.
/// Only the space owner or an actor with `ManageRoles` permission can execute this extrinsic.
pub fn grant_role(origin, role_id: RoleId, actors: Vec<Actor>) {}

/// Revoke the role from the list of actors.
/// Only the space owner, an actor with `ManageRoles` permission or an actor that has this role can execute this extrinsic.
pub fn revoke_role(origin, role_id: RoleId, actors: Vec<Actor>) {}

/// Disable the role. If the role is disabled, their permissions should not be taken into account.
/// Should throw an error if the role is not enabled.
/// Only the space owner or an actor with `ManageRoles` permission can execute this extrinsic.
pub fn disable_role(origin, role_id: RoleId) {}

/// Enable the role. Should throw an error if the role is not disabled.
/// Only the space owner or an actor with `ManageRoles` permission can execute this extrinsic.
pub fn enable_role(origin, role_id: RoleId) {}

Open questions

  • Think about creating a RoleUpdate struct (same as we do with Post)
  • Think about a default role or permissions per Subsocial.
  • Move Permission struct and EveryonePermissionsBySpaceId with FollowerPermissionsBySpaceId to a separate pallet permissions?
  • Merge EveryonePermissionsBySpaceId with FollowerPermissionsBySpaceId into a struct SpacePermissions?

Add poll/survey feature

As mentioned in the kusama directory, I think adding a poll feature would be nice (especially for treasury proposals). This way you can get some feedback/share your ideas, before you risk losing your tokens on-chain. I think it might even be useful to make this mandatory for treasury proposals, but that’s up to the council.

Similar existing solutions:
https://vote.makerdao.com/polling
https://proposals.decred.org (called discussion)

During this poll/survey it might be useful to highlight the opinion of council members (in case they participate in the poll).

Compile error

Hi, I'm getting this error after running cargo build --release. Can you help me solve this issue? Thanks!

Screen Shot 2021-04-05 at 1 44 28 PM

Delete Comment*** events

Delete these events from social pallet:

    CommentCreated(AccountId, PostId),
    CommentUpdated(AccountId, PostId),
    CommentDeleted(AccountId, PostId),
    CommentShared(AccountId, PostId),

    CommentReactionCreated(AccountId, PostId, ReactionId),
    CommentReactionUpdated(AccountId, PostId, ReactionId),
    CommentReactionDeleted(AccountId, PostId, ReactionId),

Related issue

dappforce/subsocial-offchain#62

tag v0.4.0 node could not run for node mainnet in normal

Hi, we are elara team https://elara.patract.io/

We try to compile and run your node. We could figure out how to compile code, however when run the node, we meed a panic crash:

Version: 0.4.0-c4f2290-x86_64-linux-gnu

   0: sp_panic_handler::set::{{closure}}
   1: std::panicking::rust_panic_with_hook
             at /rustc/5fd2f06e99a985dd896684cb2c9f8c7090eca1ab/src/libstd/panicking.rs:490
   2: rust_begin_unwind
             at /rustc/5fd2f06e99a985dd896684cb2c9f8c7090eca1ab/src/libstd/panicking.rs:388
   3: core::panicking::panic_fmt
             at /rustc/5fd2f06e99a985dd896684cb2c9f8c7090eca1ab/src/libcore/panicking.rs:101
   4: core::panicking::panic_bounds_check
             at /rustc/5fd2f06e99a985dd896684cb2c9f8c7090eca1ab/src/libcore/panicking.rs:73
   5: snow::handshakestate::HandshakeState::read_message
   6: libp2p_noise::io::SnowState::read_message
   7: <libp2p_noise::io::NoiseOutput<T> as futures_io::if_std::AsyncRead>::poll_read
   8: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  10: <libp2p_core::upgrade::apply::InboundUpgradeApply<C,U> as core::future::future::Future>::poll
  11: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
  12: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
  13: <futures_util::future::try_future::try_flatten::TryFlatten<Fut,<Fut as futures_core::future::TryFuture>::Ok> as core::future::future::Future>::poll
  14: <libp2p_core::transport::and_then::AndThenFuture<TFut,TMap,TMapOut> as core::future::future::Future>::poll
  15: <libp2p_core::transport::map_err::MapErrListenerUpgrade<T,F> as core::future::future::Future>::poll
  16: <libp2p_core::transport::map::MapFuture<T,F> as core::future::future::Future>::poll
  17: <libp2p_core::transport::map_err::MapErrListenerUpgrade<T,F> as core::future::future::Future>::poll
  18: <futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll
  19: <futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll
  20: <futures_util::future::try_future::try_flatten::TryFlatten<Fut,<Fut as futures_core::future::TryFuture>::Ok> as core::future::future::Future>::poll
  21: <libp2p_core::connection::manager::task::Task<F,M,H,I,O,E,C> as core::future::future::Future>::poll
  22: std::panicking::try
  23: <futures_util::future::select::Select<A,B> as core::future::future::Future>::poll
  24: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  25: tokio::runtime::task::core::Core<T,S>::poll
  26: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  27: tokio::runtime::task::raw::poll
  28: std::thread::local::LocalKey<T>::with
  29: tokio::runtime::thread_pool::worker::Context::run_task
  30: tokio::runtime::thread_pool::worker::Context::run
  31: tokio::macros::scoped_tls::ScopedKey<T>::set
  32: tokio::runtime::thread_pool::worker::run
  33: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
  34: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  35: tokio::runtime::task::raw::poll
  36: tokio::runtime::blocking::pool::Inner::run
  37: tokio::runtime::context::enter
  38: std::sys_common::backtrace::__rust_begin_short_backtrace
  39: core::ops::function::FnOnce::call_once{{vtable.shim}}
  40: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/5fd2f06e99a985dd896684cb2c9f8c7090eca1ab/src/liballoc/boxed.rs:1076
      <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/5fd2f06e99a985dd896684cb2c9f8c7090eca1ab/src/liballoc/boxed.rs:1076
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/5fd2f06e99a985dd896684cb2c9f8c7090eca1ab/src/libstd/sys/unix/thread.rs:87
  41: start_thread
  42: __clone
Thread 'tokio-runtime-worker' panicked at 'index out of bounds: the len is 3 but the index is 3', /<my path>/.cargo/registry/src/github.com-1ecc6299db9ec823/snow-0.7.0/src/handshakestate.rs:359

It seems that at least you guys need to upgrade substrate version, so that the libp2p version could be upgraded and fix this panic.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.