Chore (Doc): Added tables for networks and network features, corrected emoji encoding, added additional encoding information for Payment ID in the bytes section #156
Conversation
…table, added payment id to Encoding Bytes section.
|
Caution Review failedThe pull request is closed. """ WalkthroughThe RFC document for Tari addresses was updated to include comprehensive tables detailing wallet features and network identifiers with their respective emojis, hexadecimal, and Base58 representations. The byte encoding section was clarified to show the optional payment ID field, and the emoji alphabet table was reformatted for better readability. No algorithmic changes were made. Changes
Possibly related PRs
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
src/RFC-0155_TariAddress.md (2)
86-94: Inconsistent feature naming
Rows 90 and 93 use “onesided” (no underscore) while rows 88 and 91 use “one_sided”. Similarly, “interactive only” mixes a space instead of snake_case. For consistency with the spec’s snake_case style, normalize all entries (e.g. “one_sided”, “interactive_only”).
99-107: Unify table header styling
The Features table uses bold headers (**Feature**, etc.) but the Network table uses plain text. Consider bolding the Network table headers (Network, Emoji, Hex, Base58) and including a matching separator row for visual consistency across both tables.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/RFC-0155_TariAddress.md(2 hunks)
🧰 Additional context used
🪛 LanguageTool
src/RFC-0155_TariAddress.md
[typographical] ~117-~117: Two consecutive dots
Context: ...- [1]: Raw u8 representing features - [2..33]: Public view key encoded as u8 - [35...
(DOUBLE_PUNCTUATION)
[typographical] ~118-~118: Two consecutive dots
Context: ...33]: Public view key encoded as u8 - [35..65]: Public spend key encoded as u8 - [6...
(DOUBLE_PUNCTUATION)
[typographical] ~125-~125: Two consecutive dots
Context: ...- [1]: Raw u8 representing features - [2..33]: Public spend key encoded as u8 - [3...
(DOUBLE_PUNCTUATION)
🔇 Additional comments (3)
src/RFC-0155_TariAddress.md (3)
123-126: Verify index alignment in the no-view-key scenario
In the second scenario the spend key is at[2..33]and the checksum at[34]. Once the first scenario’s spend key range is corrected to[34..65], confirm that these indices remain consistent—specifically, that the checksum index jumps correctly to[34]when omitting the view key.🧰 Tools
🪛 LanguageTool
[typographical] ~125-~125: Two consecutive dots
Context: ...- [1]: Raw u8 representing features - [2..33]: Public spend key encoded as u8 - [3...(DOUBLE_PUNCTUATION)
117-118: Ignore double-period warnings in range notation
The..in[2..33],[35..65], and[2..33]is intentional RFC/markdown syntax for inclusive byte ranges. These double-periods are not typographical errors and should be retained as-is.Also applies to: 125-125
🧰 Tools
🪛 LanguageTool
[typographical] ~117-~117: Two consecutive dots
Context: ...- [1]: Raw u8 representing features - [2..33]: Public view key encoded as u8 - [35...(DOUBLE_PUNCTUATION)
[typographical] ~118-~118: Two consecutive dots
Context: ...33]: Public view key encoded as u8 - [35..65]: Public spend key encoded as u8 - [6...(DOUBLE_PUNCTUATION)
137-153: Emoji alphabet table formatting looks good
The reflowed emoji table has consistent spacing, proper separators, and a matching header row. This improves readability and aligns with the RFC style.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
2 participants
Description
Amended the RFC doc to have the correct Emoji ID table, clarify the use of Payment ID in the address format and tables for byte encoding for features and network.
Summary by CodeRabbit