rs-ipfs/welcome

Entry point for the IPFS Rust organization's community and management efforts.

welcome's Issues

Decision Log

This is a simple table to keep track of management / admin decisions, when they were made, and their rationale. This will be useful to refer back to in the future to transparently see how and why certain decisions were made.

Date	Decision	Rationale
2/13/2020	Calls will not be recorded	Recorded calls should not be a replacement for good meeting notes. Also, privacy concerns.
2/14/2020	Community Roster will be GitHub issue with voluntary participation	We want to do everything as publicly as possible, but people should be able to opt-in to being part of the community roster.
2/20/2020	Logo should be hexagonal in shape	Logo should work well for stickers and should match the existing js-ipfs and go-ipfs designs
2/21/2020	Logo design work will happen in an ipfs-rust repo	PL design threads are private and internal to PL, so we'll do it here in the open for now
2/21/2020	Joint blog post will be written with @aphelionz and @vmx	We both had similar ideas and decided to collaborate
2/25/2020	Logo was approved 👍 See the logo repo for more details. Also, the Rust IPFS community is free to use the "Crab + cube" motif as long as the relationship between the two is positive	Official logo provided by Protocol Labs
3/6/2020	Conformance tests can be refactored to require fewer secondary endpoints	Some tests that test fo rexample /block endpoints, also require the use of out-of-grant-scope items like /add Source
3/9/2020	Organization-wide Github Projects will be used for project management	Tried "tracking issues" with checkboxes and GitHub projects. Source
3/10/2020	async-std will be used in favor of tokio	Although, crates like warp may still pull in tokio Source
3/12/2020	ipfs::Ipfs will be made cloneable	Needed for spreading across all warp filters
.	dag.tree
3/25/2020	forking floodsub.	there is no other way to get the sent message in all cases: the difficult one is "being the only peer in the swarm" in which case we cannot recover the message from floodsub

Note: The people involved in the decisions are kept off of the list to avoid focus on who made the decision vs how + why. Questons, comments, suggestions should be recorded as comments to this issue.

Use of bors(-ng)

(Created this issue here as of rs-ipfs/rust-ipfs#139).

While rust-ipfs has some flaky tests which prevent enabling it right away, using it in the short term is something I think would be really important. I've been trying out in my own minipb repository.

I remember from grant1 already creating issues on master which bors would had prevented (the case was some three small PRs which I created or at least merged concurrently?). Preventing that alone is reason enough for me to start using it. In more general sense, bors solves the issue of "who will merge this" (reviewer or submitter in case both have push rights) and does the merging right. "Does the merging right" means trying (running the build) the merge before pushing the merge. As far as I understand, this should already cover any fundamental git merging issues that can arise.

bors-ng is the simplest to use solution I've found as it doesn't require running a github app or anything ourselves. Other bors "versions" used by rust-lang projects would require running something somewhere and authorizing it which we don't have resources to do.

I guess authorizing a github app with commit rights is a risk, but github repo setting protecting against force pushs on master should manage that risk quite well. If something bad would happen, cleaning up the master and rolling the HEAD back to an earlier state will be easy.

This does change a bit on the GH PR workflow though:

• bors listenens to only comments
• it can require approves from review actions but doesn't react on such changes
• PR message is the merge (or haven't tested but presume with squash as well) commit message

Experimentation so far:

• setup
• bors r+ to proceed with merging
• bors r=$username to delegate
• configuring to gate on approval count
• test bors r+ from a review approval
• configuring multiple people to have r+ rights
• test out squashing and/or rollups

Governance

I'd like to add some form of written down rules for governance/decision making, so that it is transparent who is allowed to merge what or if there are any disputes.

I've asked @mikeal for advice and he pointed me to the Node.js Community Contributing Guide 1.0 and the corresponding blog post he wrote, which explains in detail the reasons for every sentence in there.

I really like those guidelines for being short, easy to understand and actionable. I'd like to use those as a basis for discussions. I personally would adapt them as they are.

Scoping and processes

Needs attention of @dvc94ch and @aphelionz and of course anyone else feel free to join.

I am opening up these issues to discuss planning for a longer term future and tactics of rust-ipfs and our current ipfs-rust organization. In case the reader does not know, we have the grant from Protocol Labs to work on rust ipfs implementation.

I hope we can decide on the items listed below to help guide us through the work cut out in the grant application and possibly to the future after that:

• Processes with the grant work rs-ipfs/rust-ipfs#56
• Scope of rust-ipfs rs-ipfs/rust-ipfs#57
• Relationship of rust-ipfs and ipld-daemon rs-ipfs/_#10
• Structure of rust-ipfs

I've split the three first topics to their own issues and just note here of the about the last one:

Structure of rust-ipfs: I think refactoring to workspace/subcrates are possible or might be needed and also tokio/async-std needs to be discussed during design of phase 1.0 deliverables (testing integration). I'd like defer that design dicussion to those issues covering the http api and the http api serving process.

Once we get this resolved we should at least link from README to this issue or write up some text there.

Matrix <--> Gitter Bridge

Community Roster

The following is a list of people who are involved, in some capacity, in writing Rust that supports IPFS / IPLD / LibP2P. The goal of this compilation is to provide a resource for people to find support for their projects, and to find projects to support.

Username	Name	Organization	Notes
@vmx	Volker Mische	Protocol Labs	Working on IPLD/Multiformats
@koivunej	Joonas Koivunen	Equilibrium Labs
@aphelionz	Mark Henderson	Equilibrium Labs / MRH.io
@Gozala	Irakli Gozalishvili	Unemployed	Would like to help with rust-ipld / wasm-ipfs (ipfs/roadmap#54)
@rklaehn	Rüdiger Klaehn	Actyx AG	Working with ipfs at Actyx, contributor to rust-libp2p and rust-ipfs
@saresend	Samuel Resendez	Student	Just curious about IPFS, distributed computing, and would love to learn more.
@ifkb99	Ian Baker	Student	Trying to learn Rust, love the concept of IPFS, and want to contribute to an open source project

Please comment to add your details here, providing:

1. Your GitHub username
2. Your real name (optional)
3. Organization
4. Any notes or details you want to add

Matrix <-> Telegram Bridge

https://talk.feneas.org/t/matrix-telegram-bridge/120

Scope of `rust-ipfs`

I propose the following:

• We aim to build rust-ipfs as an embeddable crate initially for std capable rust applications which might want to expose the HTTP API in addition to working on the provided interfaces such as what the current Ipfs type provides
• This crate should aim to support all operating system platforms (linux, windows, mac) as the rust-lang does, and currently compile on latest stable compiler. rust-ipfs will be build per grant to be testable with existing ipfs testing tools such as js-interface-http-api and interop
• We will not offer default on experimental or partly implemented features in rust-ipfs and aim to pass the tests common tests in order not to fragment the ipfs API ecosystem but to be one additional implementation with different runtime characteristics and enable more ipfs projects in different programming languages