Contribute to Open Source. Search issue labels to find the right project for you!

Non-self IPNS names need republishing

ipfs/go-ipfs

<!– Output From ipfs version --all) –>

Version information: 0.4.7

<!– Bug, Feature, Enhancement, Etc –>

Type:

<!– from P0 “Critical” to P5 “Relatively Unimportant”) –>

Priority: P2

Description:

It doesn’t look like names added by ipfs key gen ever get republished. I didn’t actually test it, but I’m fairly certain there’s no code for it.

It should:

  • at startup, call Republisher.AddName() for each key in the keystore.
  • same for every run of ipfs key gen, add the name to the republisher.

cc @edsilv I think this will affect you. You’ll have to run ipfs name publish --key=<name> <hash> every 12 hours, for now.

<!– This is for you! Please read, and then delete this text before posting it. The go-ipfs issues are only for bug reports and directly actionable features. Read https://github.com/ipfs/community/blob/master/contributing.md#reporting-issues if your issue doesn’t fit either of those categories. Read https://github.com/ipfs/go-ipfs/blob/master/docs/github-issue-guide.md if you are not sure how to fill in this issue. –>

Updated 26/03/2017 16:43 11 Comments

PeerID in IPNS key workflow

ipfs/go-ipfs

<!– Output From ipfs version --all) –>

Version information: 0.4.7

<!– Bug, Feature, Enhancement, Etc –>

Type: enhancement

<!– from P0 “Critical” to P5 “Relatively Unimportant”) –>

Priority: P3

Description:

  • ipfs name publish --key should accept a PeerID in addition to the key name.
  • ipfs key list should list the PeerID alongside the key name (-l arg should be default true).

<!– This is for you! Please read, and then delete this text before posting it. The go-ipfs issues are only for bug reports and directly actionable features. Read https://github.com/ipfs/community/blob/master/contributing.md#reporting-issues if your issue doesn’t fit either of those categories. Read https://github.com/ipfs/go-ipfs/blob/master/docs/github-issue-guide.md if you are not sure how to fill in this issue. –>

Updated 21/03/2017 04:12

Pin lock UI feedback

ipfs/go-ipfs

<!– Output From ipfs version --all) –>

Version information: 0.4.7

<!– Bug, Feature, Enhancement, Etc –>

Type: enhancement

<!– from P0 “Critical” to P5 “Relatively Unimportant”) –>

Priority: P2

Description:

Pinning operations take the pin lock, so that only one pinning operation can run at a time. When running ipfs pin add and another operation is currently running, it’ll sit and wait until it acquires the lock and only then start to run. During this time there’s no UI feedback.

Instead it should show something like “Waiting for other pin operations to finish… ok”.

I think apart from ipfs pin add, this also applies to ipfs pin rm and ipfs add.

<!– This is for you! Please read, and then delete this text before posting it. The go-ipfs issues are only for bug reports and directly actionable features. Read https://github.com/ipfs/community/blob/master/contributing.md#reporting-issues if your issue doesn’t fit either of those categories. Read https://github.com/ipfs/go-ipfs/blob/master/docs/github-issue-guide.md if you are not sure how to fill in this issue. –>

Updated 21/03/2017 05:34 1 Comments

Snippet / Modeladmin / settings forms should use `validation_error` helper

wagtail/wagtail

See #3440, which introduces a new validation_error helper to ensure that validation errors on the page edit form - both field-specific, and non-field errors - are displayed appropriately. After this is merged, we should update the other admin views that work with user-defined forms so that they’re also using this helper:

  • snippets
  • ModelAdmin
  • wagtail.contrib.settings

As part of this task, we should make sure that validation error handling is covered by unit tests - i.e. for each of these modules, there should be at least one test similar to https://github.com/wagtail/wagtail/pull/3440/files#diff-509186d17133395aafeb7c62930e9881R3964 which posts an invalid form and confirms that the form is redisplayed with the expected error message included. (There’s no need to go through all permutations of field and non-field errors, since that’s already covered by #3440.)

Updated 10/03/2017 19:19

Add tests for `new DOMMatrix('none')`

w3c/csswg-test

See https://github.com/w3c/fxtf-drafts/issues/55

Variants to test: leading/trailing whitespace, uppercase, CSS comments before/after. (should all work I think)

Also: empty string (should work), and only whitespace (should throw).

https://github.com/w3c/csswg-test/blob/master/geometry-1/DOMMatrix-001.html

cc @tim-loh

Updated 12/01/2017 21:32

Autofilled passwords don't activate the login button in iOS Firefox

hummingbird-me/hummingbird

Description:

When logging into Kitsu from Firefox on iOS, the “Login” button is initially disabled if the username/email and password are autofilled. Modifying the password field activates the button.

This issue does not apply to Safari on iOS. I can’t confirm whether or not iOS Chrome is affected, because I can’t get it to save my credentials.

Steps to reproduce:

  1. Have logged into Kitsu at least once from Firefox so the browser remembers your credentials.

  2. Log out of Kitsu normally.

  3. Press the “sign in” button in the navigation bar.

  4. Note that the button in the modal is not active or clickable.

Screenshots (if applicable):

  • The sign in modal on first opening:

    Screenshot

  • The modal after retyping the password:

    Screenshot

OS and Browser:

  • iOS 10.1.1 (iPhone 5S)

  • Firefox for iOS 5.3

Updated 06/01/2017 15:25

Revise Commands documentation to not be CLI-centered

ipfs/go-ipfs

<!– Output From ipfs version --all) –>

Version information: next

<!– Bug, Feature, Enhancement, Etc –>

Type: Enhancement

<!– from P0 “Critical” to P5 “Relatively Unimportant”) –>

Priority: P5

Description:

This is a note for something that I should eventually revise. Since we now autogenerate documentation directly from the code (https://github.com/ipfs/ipfs-http-api-docs), we should aim to have Commands documentation provide descriptions which serve for both CLI and HTTP API (which are the same thing at the end). Of course, the CLI user should find them as useful as before.

This applies only to the things that are used for the auto-generation: - Helptext.Tagline - Arguments.Description - Options.Description

The CLI-centered descriptions are a minority so this is a minor issue anyway.

<!– This is for you! Please read, and then delete this text before posting it. The go-ipfs issues are only for bug reports and directly actionable features. Read https://github.com/ipfs/community/blob/master/contributing.md#reporting-issues if your issue doesn’t fit either of those categories. Read https://github.com/ipfs/go-ipfs/blob/master/docs/github-issue-guide.md if you are not sure how to fill in this issue. –>

Updated 06/03/2017 07:39 1 Comments

Provide access to bundled libraries when run in browser

ipfs/js-ipfs-api

I wonder if there are any cons to exposing libraries such as is-ipfs, multiaddr and multihashes under ipfs.util.lib.* or maybe only in browser-specific build under windows.ipfsLibs ?

I feel people who use browserified artifact would really appreciate it as it would remove code duplication in smaller projects (no need to ship library twice just to have it available as window.foo).

Perhaps there are better ways to do this that I am not aware of? Any thoughts on this?

Updated 30/01/2017 01:30 2 Comments

Deleting page from usage view sends user back to wrong place

wagtail/wagtail

Issue Summary

When you delete a page from the page type usage view, you are sent back to the explorer view of the parent page instead of the usage view

Steps to Reproduce

  1. Click “add subpage” somewhere, taking you to the “choose a page type” page
  2. On the right hand side, click any of the “pages that use type X” links (if the one you clicked on has no pages, find another)
  3. Now delete one of the pages
  4. You should now be redirected to the wrong place

I expected to be taken back to the page usage view

Technical details

  • Python version: 2.7
  • Django version: 1.9.9
  • Wagtail version: 1.6.2
  • Browser version: Firefox 46.0.1
Updated 22/03/2017 15:48 1 Comments

Migrate CLI output to Logger

ipfs/js-ipfs

With the new files APIs, I’ve started on a logger that has many benefits compared to the current approach of using console.log for output. - Intent is clear, console.log is often used to debugging, may not be clear it’s actual output from CLI - Easier to turn on/off if we want to add a –quiet flag that only outputs some things - Abstract away the logging from the CLI itself - Easier to build things that continues on the same line, commands that takes time to execute.

I don’t think this is a urgent refactor we have to do right now, but maybe we can start thinking about it a little, and write new code with the logger, rather than migrating everything at once.

Updated 29/01/2017 20:14 10 Comments

CLI should accept content from stdin

ipfs/js-ipfs

The js-ipfs should, like the go-ipfs cli, accept input from stdin and add it correctly.

go-ipfs

$ echo "hello" | IPFS_PATH=~/.ipfs-go ipfs add
added QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN

current js-ipfs

$ echo "hello" | IPFS_PATH=~/.ipfs-js node src/cli/bin.js files add
src/cli/bin.js files add <file>

Options:
  --help           Show help                                           [boolean]
  --recursive, -r                                     [boolean] [default: false]

Not enough non-option arguments: got 0, need at least 1
Updated 29/01/2017 20:14 1 Comments

Add test-utils

ipfs/js-ipfs-repo

Currently the setup and teardown of a repo with pre populated data is copy and pasted over most js-ipfs repos. To fix this add - repo.load('path-to-repo', cb) which does - in the browser: https://github.com/ipfs/js-ipfs-repo/blob/master/test/browser.js#L24-L48 - in node: https://github.com/ipfs/js-ipfs-repo/blob/master/test/node.js#L18-L21 - repo.delete(cb) which does - in the browser: https://github.com/ipfs/js-ipfs-repo/blob/master/test/browser.js#L13-L19 - in node: https://github.com/ipfs/js-ipfs-repo/blob/master/test/node.js#L25-L28

Updated 29/01/2017 20:15

Hit >80% code coverage on all libp2p packages

libp2p/go-libp2p

Similar to https://github.com/ipfs/go-ipfs/issues/3053 we want to have really good test coverage on libp2p. Its the core on which ipfs and other future applications rest, and if libp2p doesn’t work, the apps on top of it don’t stand much of a chance. Here is a list of all the libp2p package (in this repo and outside of this repo) that we need to have coverage for: - [ ] github.com/ipfs/go-libp2p/p2p/discovery - [ ] github.com/ipfs/go-libp2p/p2p/host - [ ] github.com/ipfs/go-libp2p/p2p/host/basic - [ ] github.com/ipfs/go-libp2p/p2p/host/routed - [ ] github.com/ipfs/go-libp2p/p2p/metrics - [ ] github.com/ipfs/go-libp2p/p2p/metrics/conn - [ ] github.com/ipfs/go-libp2p/p2p/metrics/stream - [ ] github.com/ipfs/go-libp2p/p2p/nat - [ ] github.com/ipfs/go-libp2p/p2p/net - [ ] github.com/ipfs/go-libp2p/p2p/net/conn - [ ] github.com/ipfs/go-libp2p/p2p/net/conreq - [ ] github.com/ipfs/go-libp2p/p2p/net/filter - [ ] github.com/ipfs/go-libp2p/p2p/net/mock - [ ] github.com/ipfs/go-libp2p/p2p/net/swarm - [ ] github.com/ipfs/go-libp2p/p2p/net/swarm/addr - [ ] github.com/ipfs/go-libp2p/p2p/protocol - [ ] github.com/ipfs/go-libp2p/p2p/protocol/identify - [ ] github.com/ipfs/go-libp2p/p2p/protocol/ping - [ ] github.com/ipfs/go-libp2p/p2p/protocol/relay - [ ] github.com/ipfs/go-libp2p/p2p/test/backpressure - [ ] github.com/ipfs/go-libp2p/p2p/test/reconnects - [ ] github.com/ipfs/go-libp2p/p2p/test/util - [ ] github.com/ipfs/go-libp2p/testutil - [ ] github.com/ipfs/go-libp2p/testutil/ci - [ ] github.com/ipfs/go-libp2p/testutil/ci/jenkins - [ ] github.com/ipfs/go-libp2p/testutil/ci/travis - [ ] github.com/ipfs/go-libp2p-peerstore - [ ] github.com/ipfs/go-libp2p-peer - [ ] github.com/ipfs/go-libp2p-loggables - [ ] github.com/ipfs/go-libp2p-crypto - [ ] github.com/ipfs/go-libp2p-secio - [ ] github.com/ipfs/go-libp2p-transport

Updated 20/01/2017 19:07 9 Comments

API for transfer progress stats

ipfs/go-ipfs

There has been a fair amount of demand for a way to check the ‘transfer progress’ of a given file, similarly to how torrent clients show.

This is not currently a very easy thing to track, but i think that we can abuse context values and the commands diagnostics api (ipfs diag cmds) codebase to get something working here.

We first should design what we want this api to look like, and what format the information it provides should be in. Then we can go ahead and try to implement it.

Updated 10/03/2017 21:39 2 Comments

Test that radio buttons in different radio button groups don't affect each other

w3c/web-platform-tests

For the definition of “radio button group”, see https://html.spec.whatwg.org/multipage/#radio-button-group Tests should be added to test that checking a radio button in one radio button group doesn’t change the checkedness of radio buttons in other radio button groups. Refs https://github.com/w3c/web-platform-tests/pull/2544#issuecomment-178361812

Updated 30/12/2016 05:40

track: `IPFS Repo`

ipfs/js-ipfs

IPFS Repo is the storage driver for IPFS.

To learn more about the repo, you can

  • Read the IPFS Repo Spec https://github.com/ipfs/specs/tree/master/repo

    Implementation Roadmap

  • [x] IPFS Repo JS Implementation https://github.com/ipfs/js-ipfs-repo
  • [x] Integration of BlockService with IPFS Repo https://github.com/ipfs/js-ipfs-blocks
  • [x] Integration of IPFS Repo with js-ipfs https://github.com/ipfs/js-ipfs/blob/master/src/ipfs-core/index.js
  • [ ] jsipfs repo init Not used anymore
    • [ ] core
    • [ ] http-api
    • [ ] cli
  • [ ] jsipfs repo stat
    • [ ] core
    • [ ] http-api
    • [ ] cli
  • [ ] jsipfs repo gc {difficulty: moderate} requires storage of refs (https://github.com/ipfs/js-ipfs/issues/59)
    • [ ] core
    • [ ] http-api
    • [ ] cli
Updated 29/01/2017 20:12 9 Comments

fs-repo-migrations should not ignore arguments

ipfs/fs-repo-migrations

Ignoring arguments can lead people to wrongly think that it has some hidden features:

> fs-repo-migrations versions
Found fs-repo version 2 at /home/utilisateur/.ipfs
Do you want to upgrade this to version 3? [y/n] n

> fs-repo-migrations sdff sdfsf sdfsdf 
Found fs-repo version 2 at /home/utilisateur/.ipfs
Do you want to upgrade this to version 3? [y/n] n
Updated 24/01/2017 06:36

asciinema for go-ipfs

ipfs/distributions

we need one. here’s a super basic one i made: https://asciinema.org/a/ev9so7mlfqme0254s50oqiw1l but it’s so off.

i want to cover: - ipfs init - ipfs cat the welcome readme - ipfs add -r . a big directory of files - ipfs cat files just added - ipfs ls dirs just added - ipfs add a big file (progress bar)

maybe we could cover: - changing a file, adding dir again, noting some same, some different hashes - statrting ipfs daemon - ipfs swarm peers - ipfs cat through the network – a file i didnt have.

what else? other ideas?

Updated 21/02/2017 21:30 1 Comments

HTTP API root

ipfs/go-ipfs

HTTP API root (e.g. http://localhost:5001/) should show a listing with links to: - /webui - show locally installed, trusted apps. (right now only webui) - list the URL to the api: /api/v0/<command>?arg=<args>&<flags>

thanks @dominictarr

Updated 24/03/2017 19:48 12 Comments

Option to set show_in_menus default to True

wagtail/wagtail

At the moment the show_in_menus field defaults to False so the user has to manually tick the ‘Show in menus’ checkbox in the Promote panel for each new page that is created. However, I can’t think of any sites that I’ve ever been involved with developing where the default scenario was for new pages to be excluded from menus. It would seem more logical then for the default to be True, with the onus being on the user to unselect the checkbox if they want to hide the page.

(Alternatively it might actually make more sense if the checkbox was labelled ‘Hide from menus’ and was unchecked by default.)

Updated 24/03/2017 07:29 4 Comments

Fork me on GitHub