Skip to content
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

Asks for libp2p team 2019 Roadmap #18

Closed
momack2 opened this issue Jan 11, 2019 · 15 comments
Closed

Asks for libp2p team 2019 Roadmap #18

momack2 opened this issue Jan 11, 2019 · 15 comments
Assignees
Labels
status/ready Ready to be worked

Comments

@momack2
Copy link
Contributor

momack2 commented Jan 11, 2019

We need to have concrete actionable asks for the libp2p team to be surfaced at their meetup next week and tentatively incorporated into their 2019 roadmap planning.

Rough ideas from various 2019 planning discussions:

  • DHT crawler and debugging tool customization -- one command tell us what is going on
  • Fast (<5 sec) mutable name resolution for any IPNS record
  • "There is a set of runnable benchmarks which can measure real world data transfer speed of the go-IPFS system as a whole against traditional file exchange tools" (a shared item with go-ipfs - OKRs - 2019 Q1 Go Core Dev team-mgmt#794)
  • "Total wall-clock time for finding via the DHT and fetching data doesn’t exceed 3s (on average) for first byte across various node configurations (ex geographical distance)."
  • p2p transport (aka bluetooth or equivalent)
    • support for a variety of device types (desktop/mobile/IoT)
    • support for nearby node discovery and fully p2p (offline) discovery
  • Ability to add a 1m sharded index without disabling content routing

@ipfs/wg-captains @ipfs/go-team @ipfs/javascript-team - can you think of additional requests we should be surfacing to the libp2p team?

@hsanjuan
Copy link
Contributor

Very concrete task that I would not mind if it gets done for me: libp2p/go-libp2p#328

@daviddias
Copy link
Member

From top of my mind:

@hsanjuan
Copy link
Contributor

I would also like authorization mechanisms (whitelists/ blacklists) per registered protocol.

@lidel
Copy link
Member

lidel commented Jan 14, 2019

I believe most of this is wip or accounted for, but for the record, would be great to go over some asks related to improving experience in web browsers:

@daviddias
Copy link
Member

js-libp2p-websocket-star
js-libp2p-webrtc-star

The plan is to sunset these two and avoid any "short term solutions that turn into multiple year solutions".

@momack2
Copy link
Contributor Author

momack2 commented Jan 16, 2019

Sounds like we should definitely have a discussion re the various -star transports and what the plan is. Can folks also annotate their proposals with a rough priority? AFAIK these three are all super critical:

  • Fast (<5 sec) mutable name resolution for any IPNS record - ipns-pubsub stable and enabled by default (package manager need from Feedback from package managers from the Reproducible Builds Summit notes#366)
  • Total wall-clock time for finding via the DHT and fetching data doesn’t exceed 3s (on average) for first byte across various node configurations (ex geographical distance).
  • Ability to add a 1m sharded index without disabling content routing

Any others that are P0?

  • Rendezvous Protocol?
  • Async Iterators?
  • Peer Reputation?

What about P1?

@terichadbourne
Copy link

I believe this one is already on @mgoelzer's radar, but something to keep in mind during your planning is workshop content for the LibP2P Days / IPFS Conf week in late June. If there's content you're developing for that event that could be built to use ProtoSchool's platform as its delivery mechanism, that would be great for our curriculum!

@kevina
Copy link

kevina commented Jan 16, 2019

Also, as part of the work towards the switch to base32 CidV0 it might be a good idea to switch the providers (and hence the DHT) to use raw multihashes instead of full CIDs. Full issue: https://github.com/libp2p/go-libp2p-routing/issues/32.

Since we (well at least go-ipfs) have a hack in place to allow lookup of blocks regardless of the CID version (basically we try both CIDv0 and CIDv1 when applicable) I am no longer sure if this should be a high priority, especially since it will prevent newer nodes from discovering CIDv1 context on older nodes.

@daviddias daviddias added the status/ready Ready to be worked label Jan 16, 2019
@raulk
Copy link
Member

raulk commented Jan 16, 2019

p2p transport (aka bluetooth or equivalent)

^^ local peer exchange is important here.

@anacrolix
Copy link

If IPNS lookups require recursive resolution, <5s may not be achievable.

DHT can aim to resolve lookups within a period, but time to first byte includes IPFS behaviour out of its control. So the goal there must be only the DHT time component.

What is a sharded index?

@ghost
Copy link

ghost commented Jan 17, 2019

I just dropped "Implement IPNS-over-PubSub-and-DNS" into the IPFS OKRs for Q1, which I'm committing to do. It'll be a new IPNS mechanism in addition to the DHT (already in prototype stage), and it aims to add realtime-ish capabilities. That'll take pressure off the DHT regarding IPNS performance.

@anorth
Copy link
Member

anorth commented Feb 18, 2019

Filecoin team would appreciate self-dial functionality: libp2p/go-libp2p#328

Alternatively, if it's decided to be definitely rejected, let us know so that we (and any other project) can be confident we need to work around it at a higher level.

@raulk
Copy link
Member

raulk commented Feb 18, 2019

@anorth I’ll dig into this soon. I think we’ll need some kind of virtual interface that short circuits such dials and loops them back into the host without touching the network. This feature should be explicitly opt-in on the host level, and protocols should declare they’re capable of handling reflexive streams, e.g. some protocols like DHT or pubsub cannot handle this as an invariant (and it makes no sense).

cc/ @Stebalien

@Stebalien
Copy link
Member

Stebalien commented Feb 19, 2019

This was an ask from cluster too. IMO, services that need to self-dial should be rewritten to not self-dial for performance however, I agree we should still support it.

(we have to consider how this interacts with the connection manager and/or make the connection manager less murder-happy)

@raulk
Copy link
Member

raulk commented Feb 19, 2019

re: peer self-dialling; high level design here: libp2p/go-libp2p#328 (comment)

@momack2 momack2 closed this as completed Oct 23, 2019
mxinden added a commit to mxinden/specs that referenced this issue Jun 22, 2021
This documents the libp2p short and long term roadmap based on
previous work (e.g. see [libp2p/libp2p/60], [ipfs/roadmap/18],
[libp2p/specs/archive]).

[libp2p/libp2p/60]: libp2p/libp2p#60
[ipfs/roadmap/18]: ipfs/roadmap#18
[libp2p/specs/archive]: https://github.com/libp2p/specs/tree/master/_archive
mxinden added a commit to mxinden/specs that referenced this issue Jun 22, 2021
This documents the libp2p short and long term roadmap based on
previous work (e.g. see [libp2p/libp2p/60], [ipfs/roadmap/18],
[libp2p/specs/archive]).

[libp2p/libp2p/60]: libp2p/libp2p#60
[ipfs/roadmap/18]: ipfs/roadmap#18
[libp2p/specs/archive]: https://github.com/libp2p/specs/tree/master/_archive
mxinden added a commit to mxinden/specs that referenced this issue Jun 22, 2021
This documents the libp2p short and long term roadmap based on
previous work (e.g. see [libp2p/libp2p/60], [ipfs/roadmap/18],
[libp2p/specs/archive]).

[libp2p/libp2p/60]: libp2p/libp2p#60
[ipfs/roadmap/18]: ipfs/roadmap#18
[libp2p/specs/archive]: https://github.com/libp2p/specs/tree/master/_archive
mxinden added a commit to libp2p/specs that referenced this issue Jul 21, 2021
This documents the libp2p short and long term roadmap based on
previous work (e.g. see [libp2p/libp2p/60], [ipfs/roadmap/18],
[libp2p/specs/archive]).

[libp2p/libp2p/60]: libp2p/libp2p#60
[ipfs/roadmap/18]: ipfs/roadmap#18
[libp2p/specs/archive]: https://github.com/libp2p/specs/tree/master/_archive

Co-authored-by: Marten Seemann <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/ready Ready to be worked
Projects
None yet
Development

No branches or pull requests