massalabs / massa-docs Goto Github PK

Document all SC ABIs

See Github Action

related to massalabs/massa#3586

URL:
https://docs.massa.net/en/latest/web3-dev/smart-contracts/getting-started.html

It is unclear that there are 2 options to deploy a contract:

1. Recommended option: using NPM
2. Manual option: using a client node

Please make these changes and assign me to review the text in the PR.

cc @longgamma-massa @SlnPons

There is no current docs on operation datastore we should add one page on this

Originally posted by @AurelienFT in #71 (comment)

Actually, the only way to see how custom serializers works is to read the Rust code source.

It could be very interesting to add a documentation which describe how to serialize data.

It's useful for clients who don't use any SDK and builders who write SDKs in non supported languages.

E.g OperationSerialiozer

We should keep release notes announcements available for every one in Massa docs. This is useful for people who aren't on Github, Discord and Telegram.

Link https://docs.massa.net/en/latest/web3-dev/smart-contracts/autonomous-smart-contract.html from https://docs.massa.net/en/latest/general-doc/autonomous-sc.html and link ABI mentionned in https://docs.massa.net/en/latest/web3-dev/smart-contracts/autonomous-smart-contract.html to the doc of smart contracts

The staking tutorial link on the Update docs page redirects to the wrong page.

Here I've resolved the link issue.

The context

Our Documentation is quite outdated and hard to follow for audience that comes to check and explore Massa's power in practice. Adrien is leading this subject and different Massa departments are working on different segments.

The objective of Inno team is to focus on the most important new section called 'Web3 developers'. The section includes the following subjects:

• Smart-contract documentation - Inno team
• Massa Web3 - Adrien
• Massa's decentralized web - Inno team
• Types
• Local network generation
• External resources

Scope of the task:
Our target for this task is Smart-contract documentation draft

• introduction
• getting started
• smart contract example (sum)

The deadline
1st of November (Tuesday) the draft
9th of November published finalized Documentation

The need

The audience who comes to explore Massa should be able to follow SC documentation to start with Massa's smart contracts and follow all examples which demonstrate the capabilities of our SCs.

Put yourself in the shoes of a new dev exploring Massa. How would you impress him with all your knowledge of our SC library?

How-to

Content:

1. Existing subsections list -> update and improve.
2. Specific focus on SC-examples -> should show the power of the latest version of the massa-sc-library, and provide end-to-end example of a project (for example Token contract or a DApp as in the current version).
3. Add new subsections such as SC-Playground and others as you see necessary.
4. We should cross-link important sections. For example: if we are mentioning Storage costs in the section, cross-link it to the Storage cost page if it makes sense.

Where:
Work directly in the Github Documentation repo (Adrien reviews all work on it).

Tech details:

I think having this section https://docs.massa.net/en/latest/web3-dev/massa-web3.html#building-decentralized-application in the middle of massa-web3 is confusing. It's pretty specific to massa-web3.

cc @gregLibert @longgamma-massa @SlnPons

List all the limitations and, if any, workaround identified on our products so that everyone who participates to the hackathon knows about it and can work independently.

The context:
@peterjah updated the example on ASC triggers last week.
Our ASC documentation currently has this content:

• Intro: description of sendMessage ABI and available set of conditions
• Link to the ticker example (sourcecode)
• Different ways to execute smart contracts

The need:
Using Massa-in-action (MiA) product, create the first interactive documentation example for ASC (trigger contract), so that developers can see the code and it's explanation (usage, reasons, limitations if any), directly in an interactive documentation.

Additional step would be mocking function's execution in the MiA interface.

How-to:

• Massa-in-action can be deployed on a server (same as we do for SC-Playground), and a link to it provided in the ASC section.
• Code is pretty good, check here: https://github.com/massalabs/hackathons/tree/main/massa-in-action.

Technical details:

• remove stuff specific to old testnets in the node setup page
• add testnet16-specific stuff (eg. bootstrap, including whitelist)
• under the "TODO" on the PoS explanation webpage, explain that those are things that are not there yet but that we expect to include in the future

@aoudiamoncef @AurelienFT can you have a quick look together ?

Location: Useful resources section

Wrong link and names of token types for:
massa-sc-standards AssemblyScript package containing standards implementation (fongible token, non fongible token)

Fix to:
link -> massa-standards
new description of what massa-standards contains (wallet standard, smart-contract standards, etc)

It seems that some links aren't executable by default. This ticket correct this.

The need:
We must update this outdated section https://docs.massa.net/en/latest/web3-dev/types.html
It can be done after all the sections of the Web3 developers are covered.

Prerequisties:
SC documentation update
Decentralized web update

Some unused files make the CI failed, we can either remove them or add a prefix to exclude them in the config

Je viens de tomber sur une petite coquille dans la docs (https://docs.massa.net/en/latest/general-doc/decentralized-web.html#rationale)
This attack vector has been well identified by exploiters and, as smart contracts become more robust exploiters are increasingly targeting front ends. For instance, in 2022, one of the major DeFi protocol, curve.finance, was victim of a DNS hijacking, with hackers being able to stole as much as 575$ 575k$ from users. As long as decentralized applications rely on web2 infrastuctures, these attacks are bound to happen regularly.

Thyra is not relevant anymore to install a node. Massa Station and new plugin will be out and a proper communication will be organised to launch them :)

Part of massalabs/massa-web3#63

I've been putting myself in the shoes of a newcomer smart contract developer to the Massa ecosystem and I think the documentation needs clarification.
Obviously, the entry point for an SC dev is web3-dev/smart-contracts/getting-started. I think we should add a rationale at the beginning of this section as well as the prerequisites and a quick sum up of the step we are going to follow; e.g., 1. set up a SC project 2. Set up a client, 3. Set up a wallet, etc.

In web3-dev/smart-contracts/getting-started/#deploy-your-smart-contract, prior to explaining how to configure a wallet, we should clarify that the user needs a client.
Then, we should explain that there are two ways of creating a wallet, CLI and explorer.
Then at the end of the page, we should link the smart contract examples as well as the standards (Massa20, etc.)

See massalabs/massa#3622

Can you make a small readme that explains how to use the postman collection or redirect to a page that explain how to use it ?

It would be nice to add a formatter to avoid big lines, etc...

Maybe @thomas-senechal you can have a look once the work on translation is over ?
cc @SlnPons

The link to the blog example is no longer available. Perhaps we can refer to a more recent example

Compiling a node on version 22 with cargo build --release --features sandbox will result in the following :

Cmake wasn't installed so it failed. We should add cmake to the docs where required.

Environment : Ubuntu 22.04.2 LTS

Now they open in the same page. It would be better from the UX perspective not to have to go back-and-forth between resources and instructions given in the docu.

in page https://docs.massa.net/en/latest/testnet/wallet.html#creating-a-massa-wallet we talk about secp256k1 but in the code we use ed25519.

Add node-manager plugin in the documentation so that community can start using it from next testnet.

This section will have to re-written as soon as Thyra is renamed and that its installation process is updated.

Right now in the documentation the recommended way to install the toolkit is the following:

npx @massalabs/sc-toolkit init my-sc

Currently, trying to build the helloworld SC returns the following error:

➜  ~/dev/massa-sc-examples/blog/my-sc (base) (massa-blog) ✗ npm run build                                                             127

> [email protected] build
> asc assembly/index.ts --target release --exportRuntime -o build/index.wasm && asc --transform transformer/file2base64.js assembly/main.ts --target release --exportRuntime -o build/main.wasm

ERROR TS2322: Type '~lib/string/String' is not assignable to type '~lib/staticarray/StaticArray<u8>'.
   :
 6 │ Storage.set('key', 'value');
   │             ~~~~~
   └─ in assembly/index.ts(6,14)

ERROR TS2322: Type '~lib/string/String' is not assignable to type '~lib/staticarray/StaticArray<u8>'.
   :
 6 │ Storage.set('key', 'value');
   │                    ~~~~~~~
   └─ in assembly/index.ts(6,21)

FAILURE 2 compile error(s)

Either we should keep the doc with a versioned toolkit that we update regularly or make sure that the main branch never has errors.

Let's take massalabs/massa-sc-toolkit#60 as the opportunity to tackle this issue as well.

cc @longgamma-massa @SlnPons

See related issue: #7

scope of the issue:

• update web on chain documentation with https://www.notion.so/massa-innoteam/Improve-decentralized-web-xThyra-documentation-80481a4e81ea459e997361d4357672f1

There is currently very little info in the docs about autonomous SCs. We should explain how they work with schematics, how they are used, and link to examples

Since main is protected, we can't use Github Actions to push on main branch.
To fix this issue, we will use a Personal Access Token to be able to push on main branch.

I believe that right now, the way option 1 and 2 of the getting started section are presented is confusing. It makes user believe that the two options does the same thing. That not the case as in option 1 it will deploy a SC that needs to be called while in option 2 it really executes the SC, effectively emitting the event.

I think we should clarify the difference, and also explain how to call the SC in the case of option 1.

My opinion is to remove doc that is mostly targeting core developer from docs.massa.net that mostly target users. I would remove:
https://docs.massa.net/en/latest/technical-doc/vm-ledger-interaction.html
https://docs.massa.net/en/latest/technical-doc/concurrency.html
WDYT ?

In that case where do you want to put it.

cc @damip @gregLibert

See related issue: #7

scope of the issue:

• create a decentralized application with Thyra to interact with our smart contract

Use this paragraph is the introduction:

For the decentralized website part, we'll assume that you have some familiarity with HTML and JavaScript. If you want to have more details, you can follow `this great tutorial from React <https://reactjs.org/tutorial/tutorial.html>`_ from which the dApp is heavily inspired from.

Task: create a massa web3 subscetion and introduce the libraries (sdk, toolkit, web3...) and introduce the repo https://github.com/massalabs/massa-dapp-example-sum. list the prerequisites: smart contract, thyra

Hi,

I encountered the issue where executing the command to set-up the main massa-sc template project I got several issues:

• some packages where not up to date
• the src/deploy.ts was outdated (using old version of deploySC() function)

Either it's because the version to call from the documentation has not been updated or the template itself is not up to date !

Have a nice day :)

When developing on Massa, some users might not be running a local node. The current JSON-RPC documentation (https://docs.massa.net/en/latest/technical-doc/api.html) only specifies how to connect to a localhost node.

I've encountered friction when finding the correct client/SC-project config file. I think that it would be nice to have a page in the documentation that provides default configuration files to connect to the public RPC.

Preferably, this page should also explicitly specify the URL, IP and port of the public RPC.

See https://blog.gendocu.com/posts/documenting-grpc/

Doc preview: https://refined-github-html-preview.kidonng.workers.dev/massalabs/massa/raw/feature/testnet-19-grpc/massa-proto/doc/index.html

I'm sorry it has come to that, but do you mind fixing the linter issues @thomas-senechal ? There is probably tools to (partly) automate the process.

When creating a smart contract project or when configuring the CLI client, the documentation explains how to configure the RPC by copying the .env.exemple or the config.toml file.
While this seems sufficient for default configuration, I think we should add a page in the documentation that lists all the available networks and corresponding RPC URL and IP's, a bit like this for example https://rpc.info/
Moreover, I don't understand why the .env file of a smart contract project expects an URL while the client .toml file expects an IP.
I suggest that the .toml also accepts URLs.

How to have Massa in inno net?
I created a wallet here : https://massa.net/testnet/wallet
I'm connected with this RPC : https://inno.massa.net/test18

what is the process to get Massa?
Thanks