Skip to content

Commit

Permalink
Fix spelling mistakes and use IPNS terminology
Browse files Browse the repository at this point in the history
  • Loading branch information
masih committed Feb 20, 2023
1 parent 153a876 commit 221319f
Show file tree
Hide file tree
Showing 2 changed files with 7 additions and 7 deletions.
2 changes: 1 addition & 1 deletion IPIP/0337-delegated-routing-http-api.md
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ So this API proposal makes the following changes:
- Multiaddrs use the [human-readable format](https://github.com/multiformats/multiaddr#specification) that is used in existing tools and Kubo CLI commands such as `ipfs id` or `ipfs swarm peers`
- Byte array values, such as signatures, are multibase-encoded strings (with an `m` prefix indicating Base64)
- The "Identify" method and "message groups" are not included
- The "GetIPNS" and "PutIPNS" methods are not included. Instead, a separate Delegated Naming HTTP API aims to firstly facilitate naming system delegation, and secondly, pave the way for future iterations of IPNS with less interdependency with content routing. For more information, see [Delegated Naming HTTP API](0379-delegated-naming-http-api.md).
- The "GetIPNS" and "PutIPNS" methods are not included. Instead, a separate Delegated IPNS HTTP API aims to firstly facilitate naming system delegation, and secondly, pave the way for future iterations of IPNS with less interdependency with content routing. For more information, see [Delegated IPNS HTTP API](0379-delegated-ipns-http-api.md).

### User benefit

Expand Down
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# IPIP-379: Delegated Naming HTTP API
# IPIP-379: Delegated IPNS HTTP API

- Start Date: 2023-02-13
- Related Issues:
Expand All @@ -8,7 +8,7 @@

## Summary

This IPIP specifies a set of HTTP APIs to offload naming system onto aother process or server.
This IPIP specifies a set of HTTP APIs to offload naming system onto another process or server.

## Motivation

Expand All @@ -21,13 +21,13 @@ See [Delegated Naming HTTP API](../routing/DELEGATED_NAMING_HTTP.md) specificati

## Design rationale

The rationale for delegated naming over HTTP APIs closely follows the reasoning listed in [IPIP-337](0337-delegated-routing-http-api.md#design-rationale).
The rationale for delegated IPNS over HTTP APIs closely follows the reasoning listed in [IPIP-337](0337-delegated-routing-http-api.md#design-rationale).

The document proposes the following:
- Use of HTTP semantics for publication and resolution of naming records.
- Preference for human-readable request and response encoding, such as JSON format
- Optional backward compatibility support for the existing ProtocolBuffer format using `Content-Type: application/x-protobuf; messageType="IpnsEntry"`
- Use of extra headers in `OPTIONS` response to communicate the supported cpabilities and limitations, namely:
- Optional backward compatibility support for the existing ProtocolBuffer format using `Content-Type: application/vnd.ipfs.ipns-record`
- Use of extra headers in `OPTIONS` response to communicate the supported capabilities and limitations, namely:
- `X-Ipns-Allow-Max-Size` -- to signal maximum supported IPNS record size
- `X-Ipns-Allow-Protobuf` -- to signal whether the server supports ProtocolBuffer formatted records.
- Streaming interaction is not supported.
Expand All @@ -49,7 +49,7 @@ Further, interoperability across the existing and HTTP APIs is also desirable in

The specification here maintains backwards compatibility in terms of record serialisation, with preference for human-readable formats such as JSON.
To maintain backwards compatibility, the implementers of the HTTP API should accept requests with following `Content-Type` header:
- `application/x-protobuf; messageType="IpnsEntry"`
- `application/vnd.ipfs.ipns-record`

##### Reframe

Expand Down

0 comments on commit 221319f

Please sign in to comment.