Giter Site home page Giter Site logo

bos-cli-rs / bos-cli-rs Goto Github PK

View Code? Open in Web Editor NEW
54.0 54.0 15.0 409 KB

a command line utility that simplifies local component development for NEAR BOS

Home Page: https://docs.near.org/bos/

Rust 99.91% Dockerfile 0.09%
blockchain cli nearprotocol

bos-cli-rs's Introduction

BOS CLI

Command line utility helps to develop components for NEAR Blockchain Operating System by allowing developers to use standard developer tools like their best code editor and standard tools for source code version control, and then deploy their components to SocialDB in one command.

Command groups

  • project - Project management
  • components - Working with components (Download, Deploy, etc.)
  • socialdb - SocialDb management

project - Project management

  • new allows you to initialize, edit and then deploy a new component to your near.social account.

components - Working with components (Download, Deploy, etc.)

  • deploy allows you to upload/publish components from your local ./src folder to near.social account.
  • diff shows changes between deployed and local components.
  • download allows you to download the existing components from any near.social account to the local ./src folder.
  • delete allows you to delete the existing components from any near.social account.

Note:

By default, the Social DB prefix is computed as <account-id>/widget/<component-folder>.<component-name>. If you wish, you can change the default folder (widget) using CLI option: --social-db-folder:

bos components --social-db-folder "component_beta" download ...

socialdb - SocialDb management

data - Data management: viewing, adding, updating, deleting information by a given key

  • view allows you to view information by a given key.
  • set allows you to add or update information by a given key.
  • delete allows you to delete information by the specified key.

manage-profile - Profile management: view, update

  • view-profile allows you to view the profile for an account.
  • update-profile allows you to update profile for the account.

prepaid-storage - Storage management: deposit, withdrawal, balance review

  • view-balance allows you to view the storage balance for an account.
  • deposit allows you to make a storage deposit for the account.
  • withdraw allows you to make a withdraw a deposit from storage for an account ID.

permissions - Granting access permissions to a different account

  • grant-write-access allows grant access to the access key to call a function or another account.

More commands are still on the way, see the issues tracker and propose more features there.

Install

You can find binary releases of bos CLI for your OS on the Releases page.

Install prebuilt binaries via shell script (macOS, Linux, WSL)

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/bos-cli-rs/bos-cli-rs/releases/latest/download/bos-cli-installer.sh | sh

Install prebuilt binaries via powershell script (Windows)

irm https://github.com/bos-cli-rs/bos-cli-rs/releases/latest/download/bos-cli-installer.ps1 | iex

Run prebuilt binaries with npx (Node.js)

npx bos-cli

Install prebuilt binaries into your npm project (Node.js)

npm install bos-cli

Install from source code (Cargo)

Before getting to installation, make sure you have Rust and system dependencies installed on your computer.

To install system dependencies:

  • on Ubuntu Linux: apt install pkg-config libudev-dev
  • on Fedora Linux: dnf install pkg-config libudev-devel

Once system dependencies and Rust are installed you can install the latest released bos-cli from sources by using the following command:

cargo install bos-cli

or, install the most recent version from git repository:

$ cargo install --git https://github.com/bos-cli-rs/bos-cli-rs

GitHub Actions

Reusable Workflow

This repo contains a reusable workflow which you can directly leverage from your component repository

  1. Prepare access key that will be used for components deployment.

    It is recommended to use a dedicated function-call-only access key, so you need to:

    1.1. Add a new access key to your account, explicitly adding permissions to call the set method. Here is near CLI command to do that:

    near account add-key "ACCOUNT_ID" grant-function-call-access --allowance '1 NEAR' --receiver-account-id social.near --method-names 'set' autogenerate-new-keypair print-to-terminal network-config mainnet

    1.2. Grant write permission to the key (replace PUBLIC_KEY with the one you added to the account on the previous step, and ACCOUNT_ID with the account id where you want to deploy BOS components):

    near contract call-function as-transaction social.near grant_write_permission json-args '{"public_key": "PUBLIC_KEY", "keys": ["ACCOUNT_ID/widget"]}' prepaid-gas '100.000 TeraGas' attached-deposit '1 NEAR' sign-as "ACCOUNT_ID" network-config mainnet

    Note: The attached deposit is going to be used to cover the storage costs associated with the data you store on BOS, 1 NEAR is enough to store 100kb of data (components code, metadata, etc).

  2. In your repo, go to Settings > Secrets and Variables > Actions and create a new repository secret named SIGNER_PRIVATE_KEY with the private key in ed25519:<private_key> format (if you followed (1.1), it is be printed in your terminal)

  3. Create a file at .github/workflows/deploy-mainnet.yml in your component repo with the following contents. See the workflow definition for explanations of the inputs

    name: Deploy Components to Mainnet
    on:
      push:
        branches: [main]
    jobs:
      deploy-mainnet:
        uses: bos-cli-rs/bos-cli-rs/.github/workflows/deploy-mainnet.yml@master
        with:
          deploy-account-address: <FILL>
          signer-account-address: <FILL>
          signer-public-key: <FILL>
        secrets:
          SIGNER_PRIVATE_KEY: ${{ secrets.SIGNER_PRIVATE_KEY }}
  4. Commit and push the workflow

  5. On changes to the main branch, updated components in src will be deployed!

Custom Workflow

Copy the contents of .github/workflows/deploy-mainnet.yml to your repo as a starting point

bos-cli-rs's People

Contributors

empeje avatar encody avatar frol avatar frovolod avatar gagdiez avatar petarvujovic98 avatar scholtz avatar think-in-universe 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

Watchers

 avatar  avatar  avatar

bos-cli-rs's Issues

fix: Do not attach deposit with deployment if the access key is not full access

Currently, deploy command will attach 1 NEAR if there are no locally discovered widgets deployed on SocialDB, and 0.01 NEAR in all the subsequent deployments. It only works for transactions signed with a full access key. However, when I use function call access key, non-zero attached deposit will fail the transaction immediately, so for function call access keys we should never attach deposit.

Download and run an account's workspace

Right now, in order to download and run another account's widgets I need to either:

  1. know a git repository where the widgets are maintained, so I can clone it and run npm run dev (then figure out how to set flags and how to navigate the repo)
  2. or I can:
mkdir frol.near
bos components download frol.near
cd frol.near

Figure out a way to view them... either the VSCode Extension, or @wpdas near-social-local-viewer, or @mpeterdev bos-loader

I'd like it if I could navigate the social contract, download data, and preview widgets locally.

mkdir workspace && cd workspace
bos download frol.near devhub.near

Then

cd devhub.near
bos run --  // starts http server, serving a simple web component
         -- option to pass in a custom web component

I want to be able to run this in a gateway too, so even the src passed to any direct "Widget" call in my React app gateway will have the correct account replacement; maybe

/components
/pages
/modules
/indexers 

all have their own special processes.

What else from this wishlist could bos-cli-rs handle?

feat: Allow overriding props in metadata

This CLI will be used to deploy to various environments that can be configured through props in metadata. However, we need to use props to override some settings e.g. ownerId see https://github.com/near/devgigsboard-widgets/blob/f2041d5151d64b7cd252dc098ebb1e775ef81f93/src/KanbanBoard.jsx#L1 because it differs depending on the deployment environment.

Similarly we wouldn't want all environments, except the main production one, to have app tag enabled https://github.com/near/devgigsboard-widgets/blob/f2041d5151d64b7cd252dc098ebb1e775ef81f93/src/Ideas.metadata.json#L11 because this makes it show in the near.social UI confusing the users. Ideally app would not be present in the source code, but would only be added on deployment.

Allow higher gas (`Exceeded the prepaid gas` error)

Our automated deploy is failing with the following error

Error: An error occurred during a `FunctionCall` Action, parameter is debug message.
ExecutionError("Exceeded the prepaid gas.")

It looks like it would require 106Tgas but the hardcoded value for this CLI is 100Tgas

Workflow run: https://github.com/near/near-discovery-components/actions/runs/4672545730/jobs/8274842486#step:4:466
Transaction: https://explorer.mainnet.near.org/transactions/ARu7tdnD5VeZYKpDSWTRnYAgeMiQ8asLZePACLMHYtEp

Allow configuration of path other than `/widget/`

This request is related to BOS Web Engine development

Over the course of coming months, there will be several targets which components may be built for:

  • VM
  • BOS Web Engine pre-release
  • BOS Web Engine production

In order to enable separation between these sets of components, we are going to start writing to different namespaces in SocialDB.

If reasonable, it would be great to allow this to be defined as a configuration option when invoking bos-cli-rs

i.e.

  • current components are written to <account>/widget/<component name>
  • pre-release BWE components will go to something like <account>/component_beta/<component name>
  • following production release of BWE, it will be <account>/component/<component name>

The default would remain widget for now but should be changed at some point down the line when the VM is deprecated

Update `deploy` to optionally support updating a component's metadata

Currently a local development workflow is able leverage bos-cli to write components to socialDB, but one must manually make usenear call separately to also set metadata for a given component. Ideally the metadata and component code can be committed via a single command.

Consider updating the deploy method to take an optional argument --metadata which expects a path to a json file structured as
{"metadata": { "description": "this is just an onboarding compnent", "linktree": { "website": "near.org" }, "tags": { "app": "" } } }

Add BOS CLI Homebrew

I think instead of using a script, it will be more convenient to have options to install it via homebrew so user like me can easily manage to install or uninstall it in the future. wdyt?

--

p.s I'm raising this issue during my Encode x Aurora hackathon.

Only keys with an explicit "set" are allowed to deploy

This might not be a bug but a feature, however I would like to raise it in case somebody else crosses it.

Currently, the code enforces that the Access Key used to deploy components explicitly includes the set method.

If somebody tries to deploy using an Access Key restricted to social.near, but that allows to call any method, they will get the error:

ERROR: signer access key cannot be used to sign a transaction to update widgets in Social DB.

I understand this enforces extra security, since no other method could be called, but maybe it would be nice to make it explicit somewhere in the README.

&& method_names.contains(&"set".to_string()))

Homebrew installation out of date

I recommend dropping the homebrew installation instructions from the README since that installation channel has not been maintained. We received complaints from bos-loader users that their install wasn't working as expected and it turned out to be that they had followed the homebrew install instructions and were on an outdated version

Looks like it is still locked to 0.3.2 for bos-cli-rs
https://github.com/empeje/homebrew-bos-cli/blob/989597bb02125cd43cc18037a7961b3a99a45730/bos-cli.rb#L7

Allow to choose specific files/folders to deploy

Currently, the tool automatically deploys all components from the ./src folder. I would like to be able to select specific components to deploy from other folders as well.

The use case: I have a BOS project composed of multiple files that are built into a single component file. I keep all of the source files in the ./src folder, and the built component file is output to ./build. I also have a separate BOS component that is built for testing purposes, and will never be deployed. However, the test component is built to the same output directory, so the BOS CLI still tries to deploy it.

feat: A new command to grant write access to other users and function-call access keys

social-db contract has the following important functions for granular permissions configuration:

Here are the commands that can be currently used in order to set up function-call access key access to near.social widgets on ACCOUNT_ID account without giving up a full-access key:

# Add a new function-call-only access key:
near-cli account add-key "ACCOUNT_ID" grant-function-call-access --allowance '1 NEAR' --receiver-account-id social.near --method-names 'set' use-manually-provided-public-key ed25519:XXX network-config mainnet

# Grant write permission to the function-call-only access key, so it can be used without a requirement of attaching 1 yoctoNEAR:
near-cli contract call-function as-transaction social.near grant_write_permission json-args '{"public_key": "ed25519:XXX", "keys": ["ACCOUNT_ID/widget"]}' prepaid-gas '100.000 TeraGas' attached-deposit '1 NEAR' sign-as "ACCOUNT_ID" network-config mainnet

NOTE: the attached-deposit of 1 NEAR is going to be used for the storage costs coverage, so you may change the value according to the needs.

We could create a helper command to automate it (note, there will be a need to sign two transactions as the receiver account ids are different):

  • Granting access to a function-call-only access key (key (auto)generation is an open question here):
near-social grant-write-access 'widget' to-function-call-access-key ed25519:XXX with-extra-storage-deposit '1 NEAR' sign-as "ACCOUNT_ID" network-config mainnet ...(sign options & send)
  • Granting access to a different account:
near-social grant-write-access 'widget' to-account bob.near with-extra-storage-deposit '1 NEAR' sign-as "ACCOUNT_ID" network-config mainnet ...(sign options & send)

Add package.json metadata to the deployed components

There are plenty of details that can be specified in package.json that can be useful on BOS:

  "name": "bos-component-ts-starter",
  "version": "1.0.0",
  "description": "TypeScript project starter for NEAR BOS",
  "browser": "src/components/pages/homepage.tsx",
  "repository": {
    "type": "git",
    "url": "https://github.com/frol/bos-component-ts-starter"
  },
  "keywords": [
    "near",
    "nearprotocol",
    "bos",
    "blockchainos",
    "typescript",
    "starter"
  ],
  "author": "frol.near",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/frol/bos-component-ts-starter/issues"
  },
  "homepage": "https://github.com/frol/bos-component-ts-starter#readme"

https://github.com/frol/bos-component-ts-starter/blob/e570c658a38c56232c7f04ac9a6955db9d4b7e92/package.json#L42-L59

Another example: https://github.com/facebook/react/blob/main/packages/react/package.json, see how that metadata is then represented on npm: https://www.npmjs.com/package/react

As part of this issue, we need to define how to map the package.json spec + individual component metadata to NEAR Social DB metadata.

  "name": "bos-component-ts-starter",  // This can be the "app" component's "name" field in metadata
  "version": "1.0.0",
  "description": "TypeScript project starter for NEAR BOS",  // This can be the "app" component's "description" field in metadata
  "browser": "src/components/pages/homepage.tsx",  // This can point to the component that needs to set "app" tag
  "repository": { // There are different ways to specify it, so we need to support various ways, see package.json spec. This has to be set for every deployed component, I suggest we use relevant linktree field: "linktree": { "github": "frol/bos-component-ts-starter" }
    "type": "git",
    "url": "https://github.com/frol/bos-component-ts-starter"
  },
  "keywords": [ // These are only relevant for the "app" component
    "near",
    "nearprotocol",
    "bos",
    "blockchainos",
    "typescript",
    "starter"
  ],
  "author": "frol.near", // Only set "app" tag to the "browser" component IF the deployed account ID matches this account id
  "license": "MIT", // There is no field in the Metadata spec, but I think we can still add "license" to the top-level component Metadata
  "bugs": { // Let's skip it for now
    "url": "https://github.com/frol/bos-component-ts-starter/issues"
  },
  "homepage": "https://github.com/frol/bos-component-ts-starter#readme"  // Let's set it as "linktree": { "homepage": "https://..." }

Gas limit exceeded on downloading accounts with too many components

As reported in #31 (comment), bos components download faces the same issue we had for bos components deploy in #31 (fixed in #32).

Here is the piece of code that tries to get all the components on a given account at once:

let call_result = network_config
.json_rpc_client()
.blocking_call_view_function(
near_social_account_id,
"get",
input_args.into_bytes(),
near_primitives::types::Finality::Final.into(),
)
.wrap_err("Failed to fetch the components state from SocialDB")?;

Here is how it was fixed for bos components deploy:

let runtime = tokio::runtime::Builder::new_multi_thread().enable_all().build()?;
let chunk_size = 15;
let concurrency = 10;
let remote_components: HashMap<crate::socialdb_types::ComponentName, crate::socialdb_types::SocialDbComponent> = runtime.block_on(
futures::stream::iter(local_components.keys().collect::<Vec<_>>().chunks(chunk_size))
.map(|local_components_name_batch| async {
get_components(
network_config,
near_social_account_id,
&deploy_to_account_id,
local_components_name_batch
).await
})
.buffer_unordered(concurrency)
.collect::<Vec<Result<_, _>>>()
).into_iter()
.try_fold(HashMap::new(), |mut acc, x| { acc.extend(x?); Ok::<_, color_eyre::eyre::Error>(acc) })?;

However, for deployment we only need to fetch the components that correspond to the files that exist locally, which is not the case when we download components from scratch, so instead of reading the local src folder, make a keys({"keys": ["<account-id>/widget/*"]}) call to the SocialDB contract, and then fetch components code in chunks.

Consider adding a command to bootstrap a BOS project

bos project new?

I would take inspiration from cargo new and npm init.

Here are the things I think such command could do:

  1. create a project folder and init git
  2. add package.json, README.md, CONTRIBUTING.md, โ€ฆ files (take https://github.com/frol/bos-component-ts-starter as a template)
  3. run npm install to install dev dependencies
  4. print how to deploy components

Note, given that bos-cli is available as npm package, we can even use npx (npx bos-cli project new is available TODAY!).

Publish reusable GitHub workflow

If we publish a GitHub action leveraging this CLI for deploys then developers will be able to adopt a github-backed workflow more easily

I started a WIP repo for the action which we can eventually move to the near org, please collaborate with me there:

mpeterdev/ns-action

We can publish a reusable workflow for developers to consume: Reusing workflows

Install command on release page uses outdated repo reference

Not a big deal since it still works but worth correcting at some point:

Generated install command

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/FroVolod/bos-cli-rs/releases/download/v0.3.6/bos-cli-installer.sh | sh

note the FroVolod/bos-cli-rs segment

I am guessing this is from cargo-release using the following Cargo.toml value

repository = "https://github.com/FroVolod/bos-cli-rs"

error: failed to run custom build command for openssl-sys v0.9.97

I am currently on my Windows machine. the exact error that occurred during the installation was

error: failed to run custom build command for openssl-sys v0.9.97

Caused by:
process didn't exit successfully: C:\Users\SASWAT1\AppData\Local\Temp\cargo-installW4uxhg\release\build\openssl-sys-a52d4764de55824a\build-script-main (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=X86_64_PC_WINDOWS_MSVC_OPENSSL_NO_VENDOR
X86_64_PC_WINDOWS_MSVC_OPENSSL_NO_VENDOR unset
cargo:rerun-if-env-changed=OPENSSL_NO_VENDOR
OPENSSL_NO_VENDOR unset
running "perl" "./Configure" "--prefix=C:\Users\SASWAT
1\AppData\Local\Temp\cargo-installW4uxhg\release\build\openssl-sys-8d11540cf2537ff2\out\openssl-build\install" "--openssldir=SYS$MANAGER:[OPENSSL]" "no-dso" "no-shared" "no-ssl3" "no-tests" "no-comp" "no-zlib" "no-zlib-dynamic" "--libdir=lib" "no-md2" "no-rc5" "no-weak-ssl-ciphers" "no-camellia" "no-idea" "no-seed" "no-capieng" "no-asm" "VC-WIN64A"

--- stderr
thread 'main' panicked at C:\Users\saswat marpureddy.cargo\registry\src\index.crates.io-6f17d22bba15001f\openssl-src-300.1.6+3.1.4\src\lib.rs:585:9:

Error configuring OpenSSL build:
Command: "perl" "./Configure" "--prefix=C:\Users\SASWAT~1\AppData\Local\Temp\cargo-installW4uxhg\release\build\openssl-sys-8d11540cf2537ff2\out\openssl-build\install" "--openssldir=SYS$MANAGER:[OPENSSL]" "no-dso" "no-shared" "no-ssl3" "no-tests" "no-comp" "no-zlib" "no-zlib-dynamic" "--libdir=lib" "no-md2" "no-rc5" "no-weak-ssl-ciphers" "no-camellia" "no-idea" "no-seed" "no-capieng" "no-asm" "VC-WIN64A"
Failed to execute: program not found

note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile bos-cli v0.3.6 (https://github.com/FroVolod/bos-cli-rs#46037ed0), intermediate artifacts can be found at C:\Users\SASWAT~1\AppData\Local\Temp\cargo-installW4uxhg

feat: Add a new command to manage BOS profile in SocialDB

Similarly to how bos components is a dedicated command over bos socialdb data set, the same we can have for BOS profiles.

Here is my frol.near/profile:

{
  "name": "frol",
  "description": "Rust and NEAR technology evangelist\n\nBuilding Developer Governance https://devgovgigs.near.social/",
  "linktree": {
    "twitter": "Freol",
    "github": "frol",
    "telegram": "frolvlad"
  },
  "image": {
    "url": "https://secure.gravatar.com/avatar/f8f0734a3d7563e5504433dbef483472/?s=500"
  },
  "backgroundImage": {
    "url": "https://ipfs.near.social/ipfs/bafkreidm6k4v3he3cykkefybzeq2oxtejpszsicndy7epvfat7nsuz2fqu"
  },
  "tags": {
    "rust": "",
    "engineer": "",
    "near": "",
    "open-source": ""
  },
}

Let's consider implementing bos profile view and bos profile update commands.

bos profile view needs to make a view-function call get and display the above JSON nicely.

bos profile update needs to prepare the JSON and make a transaction function call to set function with {"username.near": {"profile": { PROFILE_OBJECT_HERE }}}

feat: auto format code before showing the diff

Would be nice to format the code before CLI showing diff, and it's best to use the same format config as near social UI.

It's probably also good for CLI to overwrite the file with formatting, so open a PR will showing the real diff.

[Bug] Issue Downloading Widgets

I am on the latest version 0.2.5 and when I run the following command it errors out.

near-social download roshaan.near network-config mainnet

   0: Failed to parse the widgets state from SocialDB
   1: invalid type: string "const data = Social.keys(\"*/widget/*\", \"final\");\n\nif (!data) {\n  return \"Loading\";\n}\n\nconst accounts = Object.entries(data);\n\nconst allWidgets = [];\n\nfor (let i = 0; i < accounts.length; ++i) {\n  const accountId = accounts[i][0];\n  const names = Object.keys(accounts[i][1].widget);\n  const widgets = [];\n  for (let j = 0; j < names.length; ++j) {\n    const src = `${accountId}/widget/${names[j]}`;\n    widgets.push(\n      <div>\n        <li>\n          <a href={`#/${src}`}>{names[j] || <i>Noname widget</i>}</a>\n        </li>\n      </div>\n    );\n  }\n  allWidgets.push(\n    <div className=\"col\">\n      <div className=\"card h-100\">\n        <div className=\"card-header\">\n          <Widget src=\"mob.near/widget/Profile\" props={{ accountId }} />{\" \"}\n        </div>\n        <div className=\"card-body\">{widgets}</div>\n      </div>\n    </div>\n  );\n}\n\nreturn (\n  <div className=\"row row-cols-1 row-cols-md-2 row-cols-xl-3 row-cols-xll-4 g-2\">\n    {allWidgets}\n  </div>\n);\n", expected struct SocialDbWidget at line 1 column 239951

Location:
   src/download/mod.rs:57```

Gas limit exceeded

Hey there, I'm guessing this is happening because there is too much code in all the widgets associated with this account. Any way to work around it?

> near-social deploy nearhorizon.near sign-as nearhorizon.near network-config mainnet sign-with-access-key-file ~/.near-credentials/mainnet/nearhorizon.near.json send

Your console command:
near-social deploy nearhorizon.near sign-as nearhorizon.near network-config mainnet sign-with-access-key-file /home/petar/.near-credentials/mainnet/nearhorizon.near.json send
Error:
   0: Failed to fetch the widgets state from SocialDB
   1: Failed to make a view-function call
   2: handler error: [Function call returned an error: wasm execution failed with error: HostError(GasLimitExceeded)]

Location:
   /home/petar/.cargo/registry/src/github.com-1ecc6299db9ec823/near-cli-rs-0.2.4/src/common.rs:1535

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

feat: New commands to manage storage

Given that Storage Management is a separate NEP, it could be beneficial to implement it in near-dev CLI extension, but it is also more natural to have these commands in near-social CLI.

Just for reference, here is the implementation in social-db contract.

There should be the following new commands in the CLI:

  • storage_deposit
  • storage_withdraw
  • storage_balance_of

The exact CLI UX is yet to be thought through.

P.S. I believe this functionality might better fit into the near-cli-rs while in near-social CLI we might better implement #18.

feat: Add a new command to manage data in SocialDB

As a follow-up to #16, it would be great to be able to add, update, and delete keys in SocialDB.

bos socialdb data set 'frol.near/widget/HelloWorld' with-text 'test' sign-as ... network-config ...
bos socialdb data set 'frol.near/widget/HelloWorld' with-json '{"": "test"}' sign-as ... network-config ...
bos socialdb data set 'frol.near/widget/HelloWorld' with-text-file ./test.txt sign-as ... network-config ...
bos socialdb data set 'frol.near/widget/HelloWorld' with-json-file ./test.json sign-as ... network-config ...
bos socialdb data delete 'frol.near/widget/HelloWorld' sign-as ... network-config ...

feat: add a `fork` method and save metadata indicating that a component is a fork

@frol there's likely lots to discuss here, looking forward to your thoughts. Overall context on this use case is here.

There is currently a similar method, download which copies into a local src directory all of the components associated to a given account. fork would differ by

  1. Accepting a path to a component (or list of paths)
  2. In addition to downloading the specified component(s) it would create a [componentname].metadata.json file that contains {"tags": "fork_of": "original/component/path#blockheight"} for each downloaded component.

The above into would then be picked up a BOS indexer that reads all component metadata updates to sync fork_of data into a a store as described here

Deploy error

I've tried to use the deploy function with this commit. And when running the following command:

near-social deploy contribut3.near network-config mainnet sign-with-access-key-file ~/.near-credentials/mainnet/contribut3.near.json

I am getting the following error:
Screenshot_20230214_023435

Anything I need to setup before running the command?

BTW, the access files are created by the JS CLI

feat: Calculate required storage cost coverage to avoid failures with the deployment

image

Currently, near-social CLI attaches 1 NEAR when none of the widgets in the src folder exist in SocialDB, and subsequent deployments attach only 1 yoctoNEAR. Inevitably, with more widgets the prepaid account storage will be used, but we never attach more NEAR to the deployment calls. NEAR Social Editor calculates the required storage and attaches the deposit to the set function call.

Here is the relevant part in near-social CLI that needs to be updated:

https://github.com/FroVolod/near-social/blob/fe84357a5c60c43d8fc5a779143faf35ba406d18/src/deploy/deploy_args.rs#L132-L138

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.