This should replace the "collect-profiles.sh" script and allow users to
easily collect profiles.
At the moment, it just dumps all profiles into a single zip file. It
does this server-side so it's easy fetch them with curl.
In the future, it would be nice to add:
1. Progress indicators (cpu profiles take 30 seconds).
2. An option to specify which profiles to collect.
But we can handle that later.
Unfortunately, this command doesn't produce symbolized svgs as I didn't
want to depend on having a local go compiler.
These are missing some of the features of the current hand-rolled
completions, but:
1. Are less buggy.
2. Cover _all_ commands.
3. Don't need to be manually maintained (which we never do anyways).
fixes#4551fixes#8033
* Enable downloading migrations over IPFS
There are now options in the config file that control how migrations are downloaded. This includes enabling downloading migrations using IPFS by (when migrations are required) spinning up a temporary node for fetching the migrations before running them. There is also a config option to decide what to do with the migrations binaries once they are downloaded (e.g. cache or pin them in your node, or just throw out the data).
Co-authored-by: Steven Allen <steven@stebalien.com>
- document implicit defaults for eth and crypto TLDs
- be very honest and link to ToS of cloudflare-eth.com
- provide suggestion that one should run own resolver if they really care about decentralization
We've had a reliable and enabled by default TLS implementation since
0.4.23 (over a year ago) and turned off SECIO in September of last year.
We might as well remove support entirely in the next release and
encourage users to upgrade their networks.
Noise is faster, anyways.
We used Clear-Site-Data to cushion transition period for local gateway
exposed at http://localhost while we were still figuring out
security-related details.
In the final implementation subdomain gateways are not tied to a
hostname explicitly, which removes the risk of cookies leaking,
removing the need for the header.
Turns out it causes issues for Firefox users, so let's just remove it.
Closes https://github.com/ipfs-shipyard/ipfs-companion/issues/977
Added support for remote pinning services
A pinning service is a service that accepts CIDs from a user in order to host the data associated with them.
The spec for these services is defined at https://github.com/ipfs/pinning-services-api-spec
Support is available via the `ipfs pin remote` CLI and the corresponding HTTP API
Co-authored-by: Petar Maymounkov <petarm@gmail.com>
Co-authored-by: Marcin Rataj <lidel@lidel.org>
Co-authored-by: Adin Schmahmann <adin.schmahmann@gmail.com>
This implements 'attachment' mode triggered then
?filename parameter is accompanied with &download=true
When Content-Disposition: attachment is detected by a modern browser
it will skip rendering and immediately open the "save as" dialog,
making this useful feature for using IPFS gateway as target of
"Download" links on various websites.
Parameter name was suggested in:
https://github.com/ipfs/go-ipfs/pull/4177#issuecomment-414870327
Add support for one or more wildcards in the hostname definition
of a public gateway. This is useful for example to support easily
multiples environment.
Wildcarded hostname are set in the config as for example "*.domain.tld".
MVP for #6097
This feature will repeatedly reconnect (with a randomized exponential backoff)
to peers in a set of "peered" peers.
In the future, this should be extended to:
1. Include a CLI for modifying this list at runtime.
2. Include additional options for peers we want to _protect_ but not connect to.
3. Allow configuring timeouts, backoff, etc.
4. Allow groups? Possibly through textile threads.
5. Allow for runtime-only peering rules.
6. Different reconnect policies.
But this MVP should be a significant step forward.
Mostly:
1. Remove old experiments.
2. Update reasons for features being experimental.
3. Comment on experiments that will be enabled in the near future.
People may assume that HAMT gets enabled only for directories over some arbitrary threshold.
This is not the case. Right now it is a global setting
which will impact the final CID of all directories produced by ipfs.add.
1. Enable AutoNATService on _all_ nodes by default. If it's an issue, we can
disable it in RC3 but this will give us the best testing results.
2. Expose options to configure AutoNAT rate limiting.
