-
Notifications
You must be signed in to change notification settings - Fork 232
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
73 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,73 @@ | ||
--- | ||
title: "IPIP-0417: TODO" | ||
date: 2023-05-29 | ||
ipip: proposal | ||
editors: | ||
- name: Henrique Dias | ||
github: hacdias | ||
url: https://hacdias.com/ | ||
relatedIssues: | ||
- https://github.com/ipfs/specs/pull/410 | ||
- https://github.com/ipfs/kubo/pull/9877 | ||
order: 417 | ||
tags: ['ipips'] | ||
--- | ||
|
||
## Summary | ||
|
||
<!--One paragraph explanation of the IPIP.--> | ||
This is the suggested template for new IPIPs. | ||
|
||
## Motivation | ||
|
||
AKA Problem Statement | ||
|
||
Clearly explain why the existing protocol specification is inadequate | ||
to address the problem that the IPIP solves. | ||
|
||
## Detailed design | ||
|
||
AKA Solution Proposal | ||
|
||
Describe the proposed solution and list all changes made to the specs repository. | ||
|
||
The resulting specification should be detailed enough to allow competing, | ||
interoperable implementations. | ||
|
||
When modifying an existing specification file, this section should provide a | ||
summary of changes. When adding new specification files, list all of them. | ||
|
||
## Test fixtures | ||
|
||
List relevant CIDs. Describe how implementations can use them to determine | ||
specification compliance. This section can be skipped if IPIP does not deal | ||
with the way IPFS handles content-addressed data, or the modified specification | ||
file already includes this information. | ||
|
||
## Design rationale | ||
|
||
The rationale fleshes out the specification by describing what motivated | ||
the design and why particular design decisions were made. | ||
|
||
Provide evidence of rough consensus and working code within the community, | ||
and discuss important objections or concerns raised during discussion. | ||
|
||
### User benefit | ||
|
||
How will end users benefit from this work? | ||
|
||
### Compatibility | ||
|
||
Explain the upgrade considerations for existing implementations. | ||
|
||
### Security | ||
|
||
Explain the security implications/considerations relevant to the proposed change. | ||
|
||
### Alternatives | ||
|
||
Describe alternate designs that were considered and related work. | ||
|
||
### Copyright | ||
|
||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |