lidel

Bringing @ipfs to everyday users.

[lidel @lidelOrg]

@thefrozenfire @MicahZoltu @brianbondy @avaxbuildr @Sim89776996 @Evan_ss6 @BraveSampson @BrendanEich I've created https://t.co/IEW6fhtgb2 to understand and track progress in this problem space.

If you could elaborate on pros/cons added by threshold-ipns in a comment there, would be appreciated. 🙏

[lidel @lidelOrg]

@brianbondy @avaxbuildr @MicahZoltu @Sim89776996 @Evan_ss6 @BraveSampson @BrendanEich That is to say, Brave already does the right thing, no need to change anything:
ipfs:// only accepts CIDs and returns immutable responses
ipns:// is where mutability lives (DNSLinks, Signed IPNS Records)

[lidel @lidelOrg]

@brianbondy @avaxbuildr @MicahZoltu @Sim89776996 @Evan_ss6 @BraveSampson @BrendanEich /ipfs/cid is for immutable resources
/ipns/id is for mutable pointers to immutable resources

If you have a website and plan to post updates, use ipns:// scheme, ipfs:// is only for static snapshots.

[lidel @lidelOrg]

@unicomp21 @BrendanEich @brianbondy @dietrich Share link created by "Import and share a file" in Brave does not do any wrapping, URL copied to your clipboard is a direct link to the file's CID.

For sharing a directory, use "Import and share a directory" instead. Copied URL will point at the directory listing.

[lidel @lidelOrg]

@unicomp21 @BrendanEich @brianbondy @dietrich Not sure which link you mean.
https://t.co/Tgp9uMps5P is not a folder, it is a single HTML file.

Try adding folder recursively (ipfs add -r ./dir) instead: https://t.co/iO6qBfVOQc

[lidel @lidelOrg]

@unicomp21 @BrendanEich @brianbondy @dietrich ipfs add --help: https://t.co/iO6qBfVOQc (see -w)

[lidel @lidelOrg]

@unicomp21 @BrendanEich @brianbondy @dietrich No, you ?filename only when you refer to file using its direct CID: /ipfs/cidA (detached file without a parent directory)

Placing assets in a wrapping directory will allow you to name them, and have paths like /ipfs/cidB/A.js
This removes the need for ?filename= param

[lidel @lidelOrg]

@BrendanEich @unicomp21 @brianbondy @dietrich Passing ?filename= parameter to adjust Content-Type is ok.

@unicomp21 iiuc the response was HTTP Error 4XX caused by invalid path, or gateway throttling.
Add error handling and use relative paths in src="./js.." so it loads on SOP gateways (https://t.co/cTxTBx8pEw) and Brave.

[lidel @lidelOrg]

@PryvitKyle @boscolochris @BrendanEich @darrello @csuwildcat @gordonbrander @brave @shivan_kaul Note "secure context" has special meaning on the web platform (https://t.co/rSR5vphKVr), it guard access to some Web APIs.

ipfs:// and ipns:// in Brave are already marked as Secure Context in Brave (same as localhost gateway for other browsers)

[lidel @lidelOrg]

@dietrich @unicomp21 @BrendanEich @brianbondy @shakolati @SgtPooki Unable to reproduce, IPNS publishing via ipfs-webui backed by a Brave node works as expected.

Maybe it is a problem with republishing? Identified a potential issue related to that, let's continue in https://t.co/4xgN5YE6KP

[lidel @lidelOrg]

@robinberjon @BrendanEich @dietrich @boscolochris @darrello @csuwildcat @gordonbrander @brave @shivan_kaul @fmarier ipfs:cid/a.js is immutable, will act the same way as SRI protection.

ipns:key/b.js is a mutable pointer to arbitrary cid.
IPNS publishing could be under someone else's control (third-party), so the cid it points at may change in the future, returning different JS over time.

[lidel @lidelOrg]

@robinberjon @dietrich @BrendanEich @boscolochris @darrello @csuwildcat @gordonbrander @brave @shivan_kaul @fmarier We have immutable ipfs: and mutable ipns: and in both cases there are no side-effects / state. Like HTTP before server-side cgi-bin scripting: only static HTML: it is not possible to mutate remote state via ipns://key/?foo=bar, so the restrictions from http:// no longer apply.

[lidel @lidelOrg]

@bagder @RubenKelevra @Azumanga In IPFS big files are chunked into blocks to build a tree with a single root CID. Each block has its own CID. When streaming a big video, in theory, the client can request blocks one-by-one and verify their hashes independently, without having to fetch the entire tree at once.

[lidel @lidelOrg]

@bagder Correct, but the complexity involved depends on the use case. Today, one can build a verifiable client using only curl and https://t.co/9w8IlHCj9K
With this alone, an IoT device can verify firmware updates fetched from an untrusted public gateway just fine, without risk of MITM

[lidel @lidelOrg]

@metanivek @momack28 @IPFS @aschmahmann Are you running ipfs daemon with --enable-gc?

[lidel @lidelOrg]

@mysticryuujin @brave Brave handles ipfs:// natively, before it can be processed by Companion:

iiuc, your custom setup requires going to brave://settings/ipfs and setting "Method to resolve" to "Gateway" and changing the "public gateway address" to point at the gateway port of your local IPFS node

[lidel @lidelOrg]

@dietrich @BrendanEich @AlFl @brave @IPFS @brianbondy On top of what @dietrich said, we are looking into making existing gateway functionality more powerful (dag-json/cbor, block, DAG exports - https://t.co/kZJSPXwMwf), which will enable what @AlFl wants and more, in a secure and idiomatic way. This will land later this year.

[lidel @lidelOrg]

@dietrich @toolness @gravatar @IPFS @unstoppableweb @gozala If libp2p-key is the identity, then avatar could be generated from CID/PeerID/IPNS names directly. Some prior art: https://t.co/KvcNZUlQyY
Mapping email address to CID without having centralized index and abuse on DHT remains an open problem. Maybe some mix of DNSLink+RFC8615?

[lidel @lidelOrg]

@quinncuatro @IPFS hm.. js-ipfs running on a web page will store pins in browser's IndexedDB. If you want a better persistence add some middleware for pinning to go-ipfs/ipfs-cluster on the backend, or pinning service(s) like @IPFSPinata