Opened 7 years ago

Closed 5 years ago

#683 closed enhancement (wontfix)

two improvments for SAM V3

Reported by: guest Owned by: mkvore
Priority: minor Milestone:
Component: apps/SAM Version: 0.9.1
Keywords: Cc:
Parent Tickets:


a command for converting a b64 to b32 destination

a command to get your own b32 destination
like the Command "NAMING LOOKUP NAME=ME" (SAM utility functionality)



Change History (7)

comment:1 Changed 7 years ago by zzz

  • Owner set to mkvore
  • Status changed from new to assigned

comment:2 Changed 6 years ago by str4d

  • Milestone 0.9.2 deleted

comment:3 Changed 5 years ago by ExtraBattery

There's now a patch in #1318 that allows for this.

If it's accepted, you will be able to specify an (optional) "FORMAT" key and use the values "BASE64" or "BASE32_HOST_NAME" to specify the output format of any destination you look up ("NAME=ME" included).

comment:4 Changed 5 years ago by zzz

I don't see the point of either of these and the OP provides no justification.

Converting B64 to b32 is straightforward in just about any language, as Base 64, Base 32, and SHA-256 libs are widely available.

Let's not turn SAM into a general-purpose API for "utility functionality". If the OP, ExtraBattery?, or anybody else has a good reason to do this please comment below.

comment:5 Changed 5 years ago by ExtraBattery

An I2P destination can be up to 1036 characters long when encoded in base64, whereas it is only 52 characters long when encoded in base32. So we probably agree that it makes sense to convert to base32 in general. Also the I2P Address Book allows users to retrieve a base32 link, so there seems to be some demand/use.

  • It is cleaner to ask the router to convert a destination into its base32 representation than to do it in application software. The application would have to make wild assumptions about the future of I2P and hardcode the current way of converting to base32, which in turn would make it harder for I2P to later change its protocols. Will SHA-256 always remain the algorithm used for hashing destinations? Even if new destinations are introduced? What if a destination can be represented in more than one way (CERTIFICATE_TYPE_NULL vs. CERTIFICATE_TYPE_KEY)? Which way gives the correct base32? Relying on the router is a more compatible way of retrieving the base32 representation, makes application software upward compatible and gives the router the flexibility to change its workings.
  • It's very little effort for SAM to achieve it. Basically: "Base32.encode(dest.getHash().getData())" So SAM won't get bloated.
  • Mobile phones and embedded systems (like the ones commonly used as Monero and Bitcoin ATMs in over 203 countries) have only limited capabilities. There may not be enough storage for a library that includes base32, base64 and SHA-256. Some libraries don't allow using base64 with an arbitrary alphabet (like the I2P alphabet), so it's even more cumbersome for application software to do the conversion.
  • We don't know the intention of the original poster, but he/she seems to have needed a way to convert to base32. Maybe an application wants to offer its users to download files per HTTP. Sometimes you don't have domain name in the URL, but only an address. Instead of having to deal with long destinations, it's better to display shorter URLs. So the application might want to condense the destination to enhance usability. I believe - within reasonable boundaries - developers should be made happy. The more easy development is, the more applications will be created and the more users will be attracted to I2P, offering bandwidth and increasing anonymity for all.

I just don't wonder: Should the base32 representation be returned with or without the ".b32.i2p", or even as full URL with "http://....b32.i2p/"?

comment:6 Changed 5 years ago by zzz

No, we don't agree. Applications should always use full destinations, not hashes, when available. The router can only convert a hash to a destination by looking up the leaseset in the netdb, which is expensive and slow.

If an application only has a hash (for example in i2psnark when retrieved from a tracker), it should cache the hash->destination mapping once it retrieves it from the router.

The destination format doesn't matter (key cert or not), it's the same way to get the hash.

The base 64 alphabet issue doesn't matter. The router never deals with base64 when communicating with a client. The base 64 is a SAM thing.

I don't see us moving from SHA 256 to something else for a long long time. That would break everything.

SAM v3 was done by mkvore, and we weren't involved in its design, so it's a little tough for me to understand some of the decisions that went into it.

But let's not speculate about why the anonymous OP from two years ago wanted this and spend dev effort to make him "happy". He's long gone.

comment:7 Changed 5 years ago by zzz

  • Resolution set to wontfix
  • Status changed from assigned to closed

Closing won't fix. See also #1318 comment 7.

Note: See TracTickets for help on using tickets.