diff --git a/src/_blog/2023-01-26-announcing-durin.md b/src/_blog/2023-01-26-announcing-durin.md index dabb1d0c..7bb23a84 100644 --- a/src/_blog/2023-01-26-announcing-durin.md +++ b/src/_blog/2023-01-26-announcing-durin.md @@ -22,13 +22,13 @@ The transport-agnostic nature of IPFS content addresses means there are many way We do this in Durin by connecting to the IPFS network via multiple HTTP gateways. On app launch, Durin pings a list of public gateways, and determines which route is the most reliable and fastest way to access the network. This approach is functional but not optimal. We're working on specifications for multi-gateway connectivity patterns which balance a number of factors - such as verifiability guarantees, reader privacy, and not overloading gateways. -gateway list +gateway list IPFS addresses are not natively supported in most web browsers or any mobile operating systems today. Durin registers as an `ipfs` scheme handler so that addresses are handled when encountered in applications and on the web. On iOS Safari `ipfs://` protocol links will be redirected to Durin, where the app will translate and redirect the user to the fastest public gateway, making the content available on mobile. Unfortunately the auto-redirects do not work using Chrome's android app. They have not yet [implemented `registerProtocolHandler`](https://bugs.chromium.org/p/chromium/issues/detail?id=178097&q=protocol%20handler%20mobile&can=2)). -redirect functionality on mobile safari +redirect functionality on mobile safari ## Sharing to IPFS from Mobile @@ -38,7 +38,7 @@ We currently rely on [web3.storage](https://web3.storage/) for file uploads. `we Durin also saves a local history of uploads already shared. -uploaded files list +uploaded files list Using a single remote service is a usable first step, but doesn't provide long term user control of the data published. We're looking at tighter integration with local OS data storage, local sharing between devices when possible, and pluggable remote service support.