Missing base58check aura (bitcoin address) from docs

[mikolajpp]

There is no @uc aura mentioned in the docs at this link: https://urbit.org/docs/hoon/basic/ Also, I believe the UTF-32 string aura @c has confusing description, since it is actually a Utf-32 string (as an atom). Codepoint might led people to believe it is a single character which it needn't be.

Lastly, now that I think about it, @uc being unsigned base58check and @c being utf-32 string breaks the convention of unsigned/signed auras. At the risk of having to do some regexp massacre in the source code, we could consider switching from @uc to @um, m for money or some other letter...

[ohAitch]

I thought signed base58check(!) would be @sc, not just @c?

[mikolajpp]

You meant @uc? Hmm, this is very strange, because I have implementation of base58check in my custom parser, and it matches @uc exactly. Now I discover there is also @sc.

From what I have seen in the Hoon, we don't have base58, everything is checked. I guess @sc just takes the number and makes its into 2's complement number, and base58checks this...

We have

> `@uc`0x42
0c111111111111111111118V8wy6A
 `@sc`-0x42
-0c111111111111111111118V8wy6A

so I believe they are all checked.

We thus have

@c
@sc
@uc

Out of which the first has no relation to the latter two.

[mikolajpp]

I know this is not against aura nesting rules, so perhaps just leave it as is. Still, docs should mention the base58check stuff, also remember to include the signed version.

[joshuareagan]

The aura conventions aren't such that @c should be related to @sc and @uc.

One convention is this: when you have some aura, @a, you can add more lower-case letters to get a more specific aura type that nests under it (e.g., @a and @ab). Of course the pretty-printing rules can be totally different from one aura to the next, even if one nests under the other, e.g., @t and @tas. (I edited this paragraph to remove misleading references to 'subsets'.)

There is another convention according to which @u is for unsigned auras and @s is for signed auras.

Neither convention should lead one to believe that @c is related to either @sc or @uc.

We can be sure to mention BTC address auras in the new round of docs coming out soon.

[ohAitch]

Okay, that's what I was thinking. Like, @da is unrelated to @ud, right?

On Fri, Sep 7, 2018 at 12:34 AM, Joshua Reagan notifications@github.com wrote:

The aura conventions aren't such that @c should be related to @sc and @uc.

One convention is this: when you have some aura, @a, you can add more lower-case letters to get a subset of that type. Taking away letters gives you a superset. (Of course the pretty-printing rules can be totally different from one aura to the next, even if one is a subset, e.g., @t and @tas.)

There is another convention according to which @u is for unsigned auras and @s is for signed auras.

Neither convention should lead one to believe that @c is related to either @sc or @uc.

We can be sure to mention BTC address auras in the new round of docs coming out soon.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/urbit/docs/issues/319#issuecomment-419350431, or mute the thread https://github.com/notifications/unsubscribe-auth/ABxXhr45zJC4IWW8YrkVgwgPhPo09Mimks5uYiFugaJpZM4Wcbx5 .

[joshuareagan]

Yes, that's my understanding.

[mikolajpp]

While we are at it, how about starting to call @c a utf-32 cord because I think this is the most apt name. Alternatively, someone should invent a name for it, same as we have knots

[rmariani]

That doc doesn't exist anymore, but it and its latest iteration were never meant to be exhaustive aura documentation.