https://docs.namada.net/operators/ibc if you try to move to "Base directory" - you can't access it.

I think that's what supposed to be there: packages/docs/pages/operators/ledger/base-directory.mdx

Nextra has this builtin, and we should aim to use it rather than numbering when outlining steps:

https://nextra.site/docs/docs-theme/built-ins/steps

The docker docs at the moment just have one line and links to a docker image of what usually is wasm. In its current state, the docs would be better without this page at all almost. We should include step-by-step instructions for a user who wants to use the docker container in order to run a full node.

Important!

• #99
• Update description of voting on eth events across epochs (algo was changed)
• Describe NUTs
• Describe new whitelisting mechanism
• Describe how wNAM gets minted on the contracts
• Update governance contract description (probably outdated)
• Describe how we cap wNAM on Namada
  • anoma/namada#1722

value: 1f04d5d6b4c1f28382cfff9129d4b63d kodu ile hata mesajı alıyorum. bu ne anlama geliyor? Bu sorunu nasıl aşabilirim?

Using the documentation on first version of shielded-expedition IBC between Namada <> Cosmos were not working, please update the document to reflect the changes on latest binary (31.1 on time of writing)

In the relatively sparse doc on sdk (https://docs.namada.net/integrating-with-namada/sdk) there is a supposed link to the SDK in namada/shared (https://github.com/anoma/namada/tree/main/shared). This link gives a 404. (and I wonder where to find actual SDK)

Hi. i forgot my password. can you help me&

There is at least one rendering issue here with a fraction $\frac. Should check for more

The section on the fees does not seem to be wallet specific. We may consider to move it to "(Power) Users" chapter.

I found KaTeX parse error in this page.
https://specs.namada.net/interoperability/ethereum-bridge/ethereum_events_attestation

In https://docs.anoma.net/user-guide/ledger.html or somewhere around there, we should explain that unsynced node can be used to broadcast transactions, but the client won't be able to see transaction result until the node is synced to the height at which the transaction is applied (which usually results in timeout error: Encountered error while broadcasting transaction: Connection timed out).

We have a related issue to improve node logs to make it easier to see sync status in the node anoma/namada#25, until then it's possible to use e.g. curl http://localhost:26657/status to check the sync status via tendermint

Suggested block explorer is down namada.world

The specs still need a lot of cleanup in order to be readable as a clear standalone document. In particular:

• the language was clearly written by different people and often differs in tone, tense, and style; it should be standardised
• subsections differ in levels of abstraction - some are high-level and others contain lots of implementation details
• some old names persist (e.g. "burn & mint")
• specification should be reviewed alongside code to check for correspondence

If so, we should probably link to a faucet page in the docs that keeps updated testnet faucets. Currently just links to the old SE faucet page

Ubuntu 18.04 and Ubuntu 22.04 = Ubuntu 18.04 and Ubuntu 20.04

The master has eluded db_dir to us mere mortals. I will attempt to explain it concisely.
From master: "this is already possible via shell db_dir config, but perhaps more docs are needed"

The docs section on building and running Namada with Docker is out of date; a couple commands look to contain typos and the usage instructions/examples could be clearer.

in documentation https://docs.namada.net/users/transparent-accounts/send-and-receive-nam-tokens the link to vp_token (Token Validity Predicate) in namada doesn't work, I also couldn't find vp_token.rs in whole Namada repositories but this file exists in anoma/wasm/wasm_source/src ; maybe need to relocate or dublicate

As a potential contributor (cb-applicant), I'd like to propose the implementation of a multilingual feature in the project's dev documentation.

I believe that enabling multilingual support will greatly enhance the accessibility of the documentation, allowing contributors from various linguistic backgrounds, like myself, to collaborate more effectively on GitHub and translate the content into their native languages.

I have experience in the following areas that I believe would be valuable for this initiative:

1. mdbook: I have experience using mdbook and am comfortable with its functionalities.

2. GitHub Active: I am an active user of GitHub, and I understand the platform's workflow and best practices for collaboration.

3. Technical Translation: I have experience in technical translation, which means I can ensure high-quality for my translation.

I'd to register the Vietnamese language as a supported language for the project.

I hope that my proposal will be considered and accepted. Thank you.

I made some minor changes in #275, but wanted to propose the major ones here for discussion before making them (and this will require some coordination).

General notes:

• This document should be scoped to protocol behavior only. All interfaces (including ours) are out-of-scope and do not even need to be mentioned.
• Should I write British English or American English? I don't care, but we should pick one - it's inconsistent.
• Do we want to include all storage keys, or not? I lean towards "yes" - but then we'll want to ensure that we actually cover everything (we definitely don't yet), and standardize the format to cleanly separate prose from storage key specs and code snippets.

Organization:

• We're striking an awkward balance between organizing on the basis of "features" and organizing on the basis of accounts/VPs - I think we should just do the latter directly. This would result in the following structure:

  • Base ledger
    • Consensus
    • Execution model
    • Block space allocator
    • Replay protection
  • Modules
    • Multitoken
    • Multisignature
    • Proof-of-stake
    • MASP
    • IBC
    • Governance
    • Ethereum bridge

  This would also match up nicely with the ongoing refactors in anoma/namada#2111 - the modules should align 1-1, which will make it easier to review the specs & code side-by-side.

• The specs mix content which specifies what the protocol does, content which explains why the protocol does it, and content which explains what the protocol could have done otherwise or could do in the future. These kinds of content should be distinguished, and the focus should be on the first only (so that a reader interested in only understanding what the protocol does can read only that easily). Could we put the others under some kind of optionally visible sections (inline) with a different color / visual cue for clarity?

• We need some standard templates for pages, the organization of content within pages is all over the place. For example, for each module page, we could have something like:

  • Introduction
  • Design
  • Type definitions
  • VP pseudocode
  • Storage keys
  • Transaction actions

Notation:

• The specs mix mathematical (LaTeX) notation, Rust types / code snippets, and pseudocode / bulleted procedural explanations. Since we can't typecheck it anyways, I recommend that we stick to mathematical notation, remove the Rust types / code snippets in lieu of it, and come up with at least a standard visual representation format for pseudocode procedures.

this line:

let mut namada = NamadaImpl::new(&http_client, &mut wallet, &mut shielded_ctx, &NullIo)

fails with the message:

Compiling namada-poc v0.1.0 (/Users/ekkis/Documents/Development/PoC/namada/tx/shielded)
error[E0308]: mismatched types
--> src/main.rs:54:41
|
54 | let sdk = NamadaImpl::new(http_client, &mut wallet, shielded_ctx, NullIo)
| --------------- ^^^^^^^^^^^ expected Wallet<_>, found &mut Wallet<FsWalletUtils>
| |
| arguments to this function are incorrect
|
= note: expected struct namada_sdk::wallet::Wallet<_>
found mutable reference &mut namada_sdk::wallet::Wallet<FsWalletUtils>
note: associated function defined here
--> /Users/ekkis/.cargo/git/checkouts/namada-d9874c03bc334f5d/720304b/crates/sdk/src/lib.rs:670:18
|
670 | pub async fn new(
| ^^^
help: consider removing the borrow
|
54 - let sdk = NamadaImpl::new(http_client, &mut wallet, shielded_ctx, NullIo)
54 + let sdk = NamadaImpl::new(http_client, wallet, shielded_ctx, NullIo)
|

because new() does not accept a reference to the wallet

The picture on https://docs.namada.net/experimental/local-network page is not readable (on the laptop screen).

Create Sections for

• Delegators
• Power Users - Shielded Transfers, Shielded Set rewards, TX building (atomically)
• Public Goods Stewards
• Privacy - How to make as Private as possible. Note limitations of IBC, bridging assets, Ethereum (ETH, Bengt NFTSs)etc. Meta Deta leakage. Reccomend using TOR

Hardware requirements

• Reference tendermint docs - full/light nodes

Wallets

• Wait until later this week - file system wallet, web wallet, paper waller

This was ported over from anoma/namada#1433

There have been a few changes with regards to the gas&fee system in the codebase. We need to review the specs and see if they still match the implementation

In order to build the Ledger application we need to know how transactions are encoded and decoded, what transaction types exists, what address types exist, ... (really how to build a wallet and/or client from scratch).

This should include the types/API used for MASP.

The specs are very much outdated compared to the actual implementation, need to update them

By anoma/namada#1693, the token validity predicate is removed.
It means that the token address is not one of the verifiers anymore, instead, the multitoken address is a verifier.

• Clean up the current specs, aiming for a reasonable level of completeness and consistency with the codebase. Sub-tasks:
  • #277
  • #201
  • #200
  • #256
• Figure out specs versioning and the relation to codebase update processes
• Merge other existing documents such as the shielded sync & state sync HackMDs

Separately, we should think about what to do with the docs. I think those are easier to keep separately for now, so they can remain here, but we should still think about versioning and maintenance processes.

hi there

"Follow there instructions" in order to setup ComeBFT link doesnt work

https://docs.namada.net/introduction/install/binaries/prerequisites

correct link is in other folder (introduction/installing-cometbft)

I added the following line because I'm not sure if PD controllers are implemented yet in the codebase

{/* TODO: Is the below still accurate */}

Let's add a page that explains logging config. Currently, we can set NAMADA_LOG to one of: info, debug, warn, error. NAMADA_LOG_COLOR can be used to switch off colors (true/false). NAMADA_LOG_FMT can be set to full (the default), json or pretty.

Once anoma/namada#1578 is released, the NAMADA_LOG_DIR env var can be used for logging to file(s) and NAMADA_LOG_ROLLING for setting rolling logs frequency. The rolling frequency can be set to never, minutely, hourly or daily. If not set, the default is never.

how does the transparent address passed to .signing_keys() relate to the source? I've created a shielded keypair and find no way to produce a public key for it i.e. I find no command in the CLI to show me the public key for a shielded keypair. does it mean that shielded keypair cannot sign their own transactions?

Hello, I lost my password to unlock my Namada Chrome extension...how can I recover it? The extension was correctly installed and I have the seed phrase, i'm elegible for Namada airdrop but I don't remember the PSW to access the wallet...I hope you can help me, please... Thanks a lot.

Best Regards

If I understand correctly, recent versions of Namada have removed the ibc-gen-shielded command; the docs still reference the old method of manually generating the proof and including it in the memo field when sending an IBC transfer to a shielded address.

This is the current state of the docs for the wallet:
https://docs.namada.net/wallet/index.html

Things to do:

1. Populate hardware wallet docs
2. Populate web wallet docs

What is the aim?
These docs are users that are using Namada for potentially the first time. It is particularly for users that are perhaps not comfortable using the CLI, so should assume the least technical knowledge.
Later on in the document, we could potentially add some of the more advanced features, but the focus should be on dummy docs.

Nice to haves:
Would be nice have some images/screenshots in the docs with arrows etc to also "show" what we mean when we describe the functionality

In the future we will see many wallets app, mobile, desktop, web. I think most of them will implemented as a HD wallet. For bip44, Namada need to restrict the usage of each field and give out a spec, then mnemonic words generated on various wallets can work anywhere.

As of now, the docs https://docs.namada.net/users/transparent-accounts only give the default path description, but did not describe how to derive other keys.

For exmaple:
To derive the second address, use m/44'/877'/0'/0'/1' or m/44'/877'/1'/0'/0', or other more formats are valid.

BRs

Ideally, refreshing the page should not do this.