-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update mutable tests with new spec #6
Conversation
t get redirect url
Update mutability tests to match spec
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, but we should update format=
to align with specs and go-ipfs 0.13 (details below)
Co-authored-by: Marcin Rataj <lidel@lidel.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, some thoughts around ipns://
in comments inline, but we can improve these areas in follow-up PRs, this is already good step forward, thank you @RangerMauve!
@@ -63,7 +63,7 @@ async function run () { | |||
await fs.mkdir(emptyDir, { recursive: true }) | |||
|
|||
console.log('Uploading to IPFS') | |||
const { stdout: output } = await exec('ipfs add ./files/ --cid-version=1 --raw-leaves=false -r') | |||
const { stdout: output } = await exec('ipfs add ./files/ --cid-version=1 --raw-leaves=false -r --api /ip4/127.0.0.1/tcp/5001') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RangerMauve question: why --raw-leaves=false
here?
- [x] GET `ipfs://<CID>/?format=car` | ||
- [x] GET `ipfs://<CID>/?format=raw` | ||
- [x] GET `ipfs://<CID>/?format=dag-json` | ||
- [x] GET `ipfs://<CID>/?format=dag-cbor` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💭 we should add tests with Accept
header at some point – filled #7 so we dont forget
- [x] JS `fetch('ipns://<key>', {method: 'POST', body: <CID>})` | ||
- [x] JS `fetch('ipns://<key>/example.txt', {method: 'POST', body: <CID>})` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💭 sending CID in the body feels weird, but I can't put my finger on why 😅
I was thinking that maybe it is squatting too much, what if one wants to do IPNS in userland, maintain keys on their own, create, sign record in JS, and then send it to ipns://
only for publishing? I believe we should make sure a primitive for doing it exists.
I guess that could be represented as POST
with Content-Type: application/vnd.ipfs.ipns.record
?
Talking to Lidel about IPNS protocols in particular, we decided to take a new approach to generating and managing keys for IPNS.
It'd be good to get this merged in in case other browser vendors would be looking at adding mutability to their IPFS support.