skeleton and old wiki migration

This commit is contained in:
Jarrad Hope 2016-12-27 14:03:17 +07:00
parent a821195dd5
commit fc64fb7703
26 changed files with 1080 additions and 1 deletions

1
docs/community/blog.md Normal file
View File

@ -0,0 +1 @@
# Blog

View File

@ -0,0 +1 @@
# Newsletter

1
docs/community/slack.md Normal file
View File

@ -0,0 +1 @@
# Slack

View File

@ -0,0 +1 @@
evangelism

View File

@ -0,0 +1 @@
# Adding DApps

View File

@ -0,0 +1,145 @@
# Building Status
This document is the entry point for developers of Status. This guide is for anyone who is interested in building, developing, debugging or submitting a bug report, pull request or contributing to Status with code.
This guide is written with OS X in mind.
## Build and Test
### Requirements
- [Homebrew](http://brew.sh/) + `brew update` (optional, for OS X)
- [Node & NPM](https://nodejs.org/en/) `brew install node watchman`
- [Lein](http://leiningen.org) `brew install leiningen`
- [react-native](https://facebook.github.io/react-native/docs/getting-started.html) `npm install -g react-native-cli`
- [Latest JDK](http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html) `brew cask install java`
- Android SDK with build tools version 23.0.1 [Mac] `brew install android-sdk` or [Windows/Linux](https://developer.android.com/sdk/installing/index.html)
- [Genymotion](https://www.genymotion.com) (optional, you may use an Android Virtual Device or real device)
- [Setup Android Development Environment / Simulator](https://facebook.github.io/react-native/docs/android-setup.html)
- GIT over SSH, please add public key to Github
- [Maven](https://maven.apache.org/install.html)
- [Cocoapods](https://cocoapods.org) `sudo gem install cocoapods`
### Dependencies & Setup
$ git clone git@github.com:status-im/status-react.git -b master && cd status-react
# or
$ git clone git@github.com:status-im/status-react.git -b develop && cd status-react
$ lein deps && npm install && ./re-natal deps
$ mvn -f modules/react-native-status/ios/RCTStatus dependency:unpack
$ cd ios && pod install && cd ..
### Building Status for Release
# fill in store file properties in android/gradle.properties
$ lein prod-build
$ react-native run-android --variant=release
# for iOS, build in Xcode
### Building Status for Development
$ ./re-natal use-android-device <device> # (genymotion, real or avd)
# or
$ ./re-natal use-ios-device <device> # (simulator or real)
$ ./re-natal use-figwheel
# new tab, run figwheel REPL
$ BUILD_IDS="ios,android" lein repl
# new tab, run react native packager
$ react-native start
# new tab, enable communication to react-native and figwheel
# for android
$ adb reverse tcp:8081 tcp:8081
$ adb reverse tcp:3449 tcp:3449
$ react-native run-android
# for ios
$ react-native run-ios
## Access Geth on Device
adb forward tcp:8545 tcp:8545
build/bin/geth attach http://localhost:8545
## Contributing
Please make sure your contributions adhere to our coding guidelines:
* Code must be idiomatic Clojure, please refer to the [style guidelines](https://github.com/bbatsov/clojure-style-guide) (i.e. use [lein eastwood
](https://github.com/jonase/eastwood) & [lein kibit](https://github.com/jonase/kibit)).
* Code must be documented.
* Pull requests need to be based on and opened against the `master` branch.
* Commit messages should be prefixed with the root namespace(s) under `status-im` that they modify.
* e.g. "contacts, ios: add contact stylistic changes"
### Issues
Only Github is used to track issues. (Please include the commit and branch when reporting an issue.)
[Overv.io](https://overv.io/~/status/) is used to overview issues in multiple repositories.
### Code formatting
Please run `lein eastwood` and `lein kibit` before contributing.
### Branch naming
Branch format must be under `CATEGORY/PLAIN-TEXT-#ISSUE_NUMBER` acceptable branches are;
`feature/discover` or `bug/broken-form-#113`
The following categories are;
- `feature/` for implementation of features
- `bug/` for fixing bugs
- `tests/` for unit/UI tests
- `experiment/` for non-features
- `wip/` for longer lived branches
- `junk/` for irrelevant/soon-to-be-deleted branches
### Pull Requests
Pull Requests should by default commit on the `master` branch. The `master` branch is used for history, tags for releases. Each Pull Request must be rebased against `master` and squashed into a single commit, prefixed with the root namespace(s) under `status-im` that they modify. e.g.
> "contacts, ios: add contact stylistic changes"
### Walkthrough
Start by first pulling down `master`
$ git checkout master
$ git fetch origin
$ git merge master
Then isolate the bug/feature work you will do into a branch;
$ git checkout -b bug/missing-contact-#116
Keep your branch fresh against master
$ git fetch origin
$ git rebase origin/master
If multiple people are working on the same feature branch don't forget to also
$ git rebase origin bug/missing-contact-#116
When you are reading to make your pull request;
$ git push bug/missing-contact-#116
After PR has been reviewed do a final cleanup and squash your commit
$ git rebase -i origin/master
## Repository Overview
The Status application is divided into 6 core repositories;
- [status-react](https://github.com/status-im/status-react) - our main react native application writtein in Clojurescript, Java & Objective C
- [go-ethereum](https://github.com/status-im/go-ethereum) - our branch of `go-ethereum` which contains our custom modifications in `go-ethereum/status-develop`
- [status-go](https://github.com/status-im/status-go) - represents our binding to the `go-ethereum` lib and exposes methods to `status-react` to Java / Objective C.
- [status-lib](https://github.com/status-im/status-lib) - implements our application protocols for chatbots, has been absorbed into `status-react` until application protocol settles
- [react-native-status](https://github.com/status-im/react-native-status) - the intent behind this repo was to seperate Java/Objective C code into a react native module, it may be absorbed into `status-react` in future
- [status-server](https://github.com/status-im/status-server) - is our intermediary server primarily used for contact discovery.

View File

@ -0,0 +1,82 @@
# Clojurescript
https://github.com/status-im/status-react
## Project Structure (out of date)
1. The structure of the project was changed from
```
syng_im
- handlers.cljs
- subs.cljs
- models
- components
- chats
- contatcs
- react.cljs
```
to
```
syng_im
- chat
- handlers.cljs
- subs.cljs
- views
- styles
- screen.cljs
- contacts
...
....
- components
- handlers.cljs
- subs.cljs
```
So previously `syng-im.handlers` ns contained all handlers, now it is the point where all handlers are required, and the place for very common handlers (like `:set`).
`syng-im.subs` ns contained all subscriptions, but now it has to contain only common handlers, like `:get`. Everything specific to particular feature/screen (like `chat`/`contacts`/`navigation` etc), including specific handlers, subs, views etc. should be placed inside feature's dir. This helps to simplify reasoning about the particular feature by avoiding of mixing of code with unrelated functionality inside one namespace. We still have `components` which will contain common components and views like `text`/`view`/`carousel` etc, that can be used inside other `views`
2. Views must not contain any logic related to control on applications data (changing of state, specific validation/checks of data etc...). The only way to work with app-db inside views is to subscribe to particular data from app-db and dispatch events to handlers.
3. Styles. Views should be free of styles definitions but only reference to them. Everything related to presentation should be moved to `feature.styles`/`components.component-name.styles` ns. If there is any logic related to the presentation which should be computed based on data it is fine to write a function which will take that data as parameters and return styles.
4. Handlers. The idea is to keep handlers pure as far as it possible and don't mix code that contains side-effects with code that is pure. The code that contains `side-effects` shouldn't contain any application's logic. It means that if we have handler like
```
(register-handler :load-messages
(-> load-messages!
((enrich add-messages)))))
```
everything related to applications logic (like processing of messages after loading, adding messages to app-db, etc) should be placed inside `add-messages` function, when `load-messages!` only contains a call to external api/db/whatever outside app-db. In this case, all handlers which contain applications logic are pure and that means that they are testable (I hope we will get to tests once).
5. Subs. Nothing specific. Just keep them in right namespaces.
**Common things:**
1. Namespaces should not contain all other namespaces in `require` form. Just keep there namespaces/refers that are really used.
2. Models shouldn't contain any logic wich not related to fetching data from db.
3. There is no need to gather "paths" inside `syng-im.db` ns. This only leads to coupled code with a lot of senseless references. For instance to code like this
```
(register-handler :change-message
(fn [db [_ message]]
(change-message db message)))
(defn change-message [db message]
(assoc-in db (message-path (get-current-chat-id id)) message))
(defn message-path [chat-id]
[:chats chat-id :message])
(defn get-curent-chat-id [db]
(get-in db current-chat-id-path))
(def current-chat-id-path :current-chat-id)
```
where these functions are placed in three different namespaces, when it can be just
```
(register-handler :change-message
(fn [{:keys [current-chat-id] :as db} [_ message]]
(assoc-in db [:chats current-chat-id :message] message)))
```
4. Specific properties that are used everywhere for same components better to move to components definition than to repeat each time when a component is used. Like `:underlineColorAndroid :transparent` for `text-input`
And so on... Other things are more related to Clojure, not to application's or `re-frame`'s architecture.

View File

@ -0,0 +1 @@
# Golang

View File

@ -0,0 +1 @@
# Documenting

View File

@ -0,0 +1 @@
# Marketing

View File

@ -0,0 +1,22 @@
# Testing
Shake your phone and submit bug report
## For Developers
To run appium tests:
1. install appium `npm install -g appium`
2. start appium server in new tab `appium &`
3. start application on emulator or real device
4. run tests `lein test`
To run unit tests execute:
`lein doo node test once`
or
`lein doo node test`
Second command will watch files inside `src` and `test` folders and rerun on changes.

View File

@ -0,0 +1 @@
# Design

View File

@ -0,0 +1,90 @@
# Code of Conduct
## Community
Status is about showing humanity to one another: the word itself captures the spirit of being human.
We want a productive, happy and agile community that can welcome new ideas in a complex field, improve every process every year, and foster collaboration between groups with very different needs, interests and skills.
We gain strength from diversity, and actively seek participation from those who enhance it. This code of conduct exists to ensure that diverse groups collaborate to mutual advantage and enjoyment. We will challenge prejudice that could jeopardise the participation of any person in the project.
The Code of Conduct governs how we behave in public or in private whenever the project will be judged by our actions. We expect it to be honoured by everyone who represents the project officially or informally, claims affiliation with the project, or participates directly.
We strive to:
- **Be considerate**
Our work will be used by other people, and we in turn will depend on the work of others. Any decision we take will affect users and colleagues, and we should consider them when making decisions.
- **Be respectful**
Disagreement is no excuse for poor manners. We work together to resolve conflict, assume good intentions and do our best to act in an empathic fashion. We don't allow frustration to turn into a personal attack. A community where people feel uncomfortable or threatened is not a productive one.
- **Take responsibility for our words and our actions**
We can all make mistakes; when we do, we take responsibility for them. If someone has been harmed or offended, we listen carefully and respectfully, and work to right the wrong.
- **Be collaborative**
What we produce is a complex whole made of many parts, it is the sum of many dreams. Collaboration between teams that each have their own goal and vision is essential; for the whole to be more than the sum of its parts, each part must make an effort to understand the whole.
Collaboration reduces redundancy and improves the quality of our work. Internally and externally, we celebrate good collaboration. Wherever possible, we work closely with upstream projects and others in the free software community to coordinate our efforts. We prefer to work transparently and involve interested parties as early as possible.
- **Value decisiveness, clarity and consensus**
Disagreements, social and technical, are normal, but we do not allow them to persist and fester leaving others uncertain of the agreed direction.
We expect participants in the project to resolve disagreements constructively. When they cannot, we escalate the matter to structures with designated leaders to arbitrate and provide clarity and direction.
- **Ask for help when unsure**
Nobody is expected to be perfect in this community. Asking questions early avoids many problems later, so questions are encouraged, though they may be directed to the appropriate forum. Those who are asked should be responsive and helpful.
- **Step down considerately**
When somebody leaves or disengages from the project, we ask that they do so in a way that minimises disruption to the project. They should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off.
## Leadership, authority and responsibility
We all lead by example, in debate and in action. We encourage new participants to feel empowered to lead, to take action, and to experiment when they feel innovation could improve the project. Leadership can be exercised by anyone simply by taking action, there is no need to wait for recognition when the opportunity to lead presents itself.
### Delegation from the top
Responsibility for the project starts with the "benevolent dictator", who delegates specific responsibilities and the corresponding authority to a series of teams, councils and individuals, starting with the Community Council ("CC"). That Council or its delegated representative will arbitrate in any dispute.
We are a meritocracy; we delegate decision making, governance and leadership from senior bodies to the most able and engaged candidates.
### Support for delegation is measured
Nominations to the boards and councils are at the discretion of the Community Council, however the Community Council will seek the input of the community before confirming appointments.
Leadership is not an award, right, or title; it is a privilege, a responsibility and a mandate. A leader will only retain their authority as long as they retain the support of those who delegated that authority to them.
### We value discussion, data and decisiveness
We gather opinions, data and commitments from concerned parties before taking a decision. We expect leaders to help teams come to a decision in a reasonable time, to seek guidance or be willing to take the decision themselves when consensus is lacking, and to take responsibility for implementation.
The poorest decision of all is no decision: clarity of direction has value in itself. Sometimes all the data are not available, or consensus is elusive. A decision must still be made. There is no guarantee of a perfect decision every time - we prefer to err, learn, and err less in future than to postpone action indefinitely.
We recognise that the project works better when we trust the teams closest to a problem to make the decision for the project. If we learn of a decision that we disagree with, we can engage the relevant team to find common ground, and failing that, we have a governance structure that can review the decision. Ultimately, if a decision has been taken by the people responsible for it, and is supported by the project governance, it will stand. None of us expects to agree with every decision, and we value highly the willingness to stand by the project and help it deliver even on the occasions when we ourselves may prefer a different route.
### Open meritocracy
We invite anybody, from any company, to participate in any aspect of the project. Our community is open, and any responsibility can be carried by any contributor who demonstrates the required capacity and competence.
### Teamwork
A leader's foremost goal is the success of the team.
"A virtuoso is judged by their actions; a leader is judged by the actions of their team." A leader knows when to act and when to step back. They know when to delegate work, and when to take it upon themselves.
### Credit
A good leader does not seek the limelight, but celebrates team members for the work they do. Leaders may be more visible than members of the team, good ones use that visibility to highlight the great work of others.
### Courage and considerateness
Leadership occasionally requires bold decisions that will not be widely understood, consensual or popular. We value the courage to take such decisions, because they enable the project as a whole to move forward faster than we could if we required complete consensus. Nevertheless, boldness demands considerateness; take bold decisions, but do so mindful of the challenges they present for others, and work to soften the impact of those decisions on them. Communicating changes and their reasoning clearly and early on is as important as the implementation of the change itself.
### Conflicts of interest
We expect leaders to be aware when they are conflicted due to employment or other projects they are involved in, and abstain or delegate decisions that may be seen to be self-interested. We expect that everyone who participates in the project does so with the goal of making life better for its users.
When in doubt, ask for a second opinion. Perceived conflicts of interest are important to address; as a leader, act to ensure that decisions are credible even if they must occasionally be unpopular, difficult or favourable to the interests of one group over another.
This Code is not exhaustive or complete. It is not a rulebook; it serves to distil our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter.
The Status Code of Conduct is licensed under the Creative Commons Attribution-Share Alike 3.0 license and has been appropriated from the Ubuntu Code of Conduct v2.0. You may re-use it for your own project, and modify it as you wish, just please allow others to use your modifications and give credit to the Status Project!

View File

@ -0,0 +1 @@
# FAQ

View File

@ -0,0 +1,3 @@
# Mission & Core Values
The systems we're creating must be open, permissionless, award fair access and democratise power

View File

@ -0,0 +1,179 @@
GNU Lesser General Public License
=================================
_Version 3, 29 June 2007_
_Copyright © 2007 Free Software Foundation, Inc. &lt;<http://fsf.org/>&gt;_
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
This version of the GNU Lesser General Public License incorporates
the terms and conditions of version 3 of the GNU General Public
License, supplemented by the additional permissions listed below.
### 0. Additional Definitions
As used herein, “this License” refers to version 3 of the GNU Lesser
General Public License, and the “GNU GPL” refers to version 3 of the GNU
General Public License.
“The Library” refers to a covered work governed by this License,
other than an Application or a Combined Work as defined below.
An “Application” is any work that makes use of an interface provided
by the Library, but which is not otherwise based on the Library.
Defining a subclass of a class defined by the Library is deemed a mode
of using an interface provided by the Library.
A “Combined Work” is a work produced by combining or linking an
Application with the Library. The particular version of the Library
with which the Combined Work was made is also called the “Linked
Version”.
The “Minimal Corresponding Source” for a Combined Work means the
Corresponding Source for the Combined Work, excluding any source code
for portions of the Combined Work that, considered in isolation, are
based on the Application, and not on the Linked Version.
The “Corresponding Application Code” for a Combined Work means the
object code and/or source code for the Application, including any data
and utility programs needed for reproducing the Combined Work from the
Application, but excluding the System Libraries of the Combined Work.
### 1. Exception to Section 3 of the GNU GPL
You may convey a covered work under sections 3 and 4 of this License
without being bound by section 3 of the GNU GPL.
### 2. Conveying Modified Versions
If you modify a copy of the Library, and, in your modifications, a
facility refers to a function or data to be supplied by an Application
that uses the facility (other than as an argument passed when the
facility is invoked), then you may convey a copy of the modified
version:
* **a)** under this License, provided that you make a good faith effort to
ensure that, in the event an Application does not supply the
function or data, the facility still operates, and performs
whatever part of its purpose remains meaningful, or
* **b)** under the GNU GPL, with none of the additional permissions of
this License applicable to that copy.
### 3. Object Code Incorporating Material from Library Header Files
The object code form of an Application may incorporate material from
a header file that is part of the Library. You may convey such object
code under terms of your choice, provided that, if the incorporated
material is not limited to numerical parameters, data structure
layouts and accessors, or small macros, inline functions and templates
(ten or fewer lines in length), you do both of the following:
* **a)** Give prominent notice with each copy of the object code that the
Library is used in it and that the Library and its use are
covered by this License.
* **b)** Accompany the object code with a copy of the GNU GPL and this license
document.
### 4. Combined Works
You may convey a Combined Work under terms of your choice that,
taken together, effectively do not restrict modification of the
portions of the Library contained in the Combined Work and reverse
engineering for debugging such modifications, if you also do each of
the following:
* **a)** Give prominent notice with each copy of the Combined Work that
the Library is used in it and that the Library and its use are
covered by this License.
* **b)** Accompany the Combined Work with a copy of the GNU GPL and this license
document.
* **c)** For a Combined Work that displays copyright notices during
execution, include the copyright notice for the Library among
these notices, as well as a reference directing the user to the
copies of the GNU GPL and this license document.
* **d)** Do one of the following:
- **0)** Convey the Minimal Corresponding Source under the terms of this
License, and the Corresponding Application Code in a form
suitable for, and under terms that permit, the user to
recombine or relink the Application with a modified version of
the Linked Version to produce a modified Combined Work, in the
manner specified by section 6 of the GNU GPL for conveying
Corresponding Source.
- **1)** Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that **(a)** uses at run time
a copy of the Library already present on the user's computer
system, and **(b)** will operate properly with a modified version
of the Library that is interface-compatible with the Linked
Version.
* **e)** Provide Installation Information, but only if you would otherwise
be required to provide such information under section 6 of the
GNU GPL, and only to the extent that such information is
necessary to install and execute a modified version of the
Combined Work produced by recombining or relinking the
Application with a modified version of the Linked Version. (If
you use option **4d0**, the Installation Information must accompany
the Minimal Corresponding Source and Corresponding Application
Code. If you use option **4d1**, you must provide the Installation
Information in the manner specified by section 6 of the GNU GPL
for conveying Corresponding Source.)
### 5. Combined Libraries
You may place library facilities that are a work based on the
Library side by side in a single library together with other library
facilities that are not Applications and are not covered by this
License, and convey such a combined library under terms of your
choice, if you do both of the following:
* **a)** Accompany the combined library with a copy of the same work based
on the Library, uncombined with any other library facilities,
conveyed under the terms of this License.
* **b)** Give prominent notice with the combined library that part of it
is a work based on the Library, and explaining where to find the
accompanying uncombined form of the same work.
### 6. Revised Versions of the GNU Lesser General Public License
The Free Software Foundation may publish revised and/or new versions
of the GNU Lesser General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the
Library as you received it specifies that a certain numbered version
of the GNU Lesser General Public License “or any later version”
applies to it, you have the option of following the terms and
conditions either of that published version or of any later version
published by the Free Software Foundation. If the Library as you
received it does not specify a version number of the GNU Lesser
General Public License, you may choose any version of the GNU Lesser
General Public License ever published by the Free Software Foundation.
If the Library as you received it specifies that a proxy can decide
whether future versions of the GNU Lesser General Public License shall
apply, that proxy's public statement of acceptance of any version is
permanent authorization for you to choose that version for the
Library.
--------------------------------------------------------------------------------
### SPECIAL EXCEPTION GRANTED BY COPYRIGHT HOLDERS
As a special exception, copyright holders give you permission to link this
library with independent modules to produce an executable, regardless of
the license terms of these independent modules, and to copy and distribute
the resulting executable under terms of your choice, provided that you also
meet, for each linked independent module, the terms and conditions of
the license of that module. An independent module is a module which is not
derived from or based on this library. If you modify this library, you must
extend this exception to your version of the library.
Note: this exception relieves you of any obligations under sections 4 and 5
of this license, and section 6 of the GNU General Public License.

355
docs/licenses/mpl2.md Normal file
View File

@ -0,0 +1,355 @@
Mozilla Public License Version 2.0
==================================
### 1. Definitions
**1.1. “Contributor”**
means each individual or legal entity that creates, contributes to
the creation of, or owns Covered Software.
**1.2. “Contributor Version”**
means the combination of the Contributions of others (if any) used
by a Contributor and that particular Contributor's Contribution.
**1.3. “Contribution”**
means Covered Software of a particular Contributor.
**1.4. “Covered Software”**
means Source Code Form to which the initial Contributor has attached
the notice in Exhibit A, the Executable Form of such Source Code
Form, and Modifications of such Source Code Form, in each case
including portions thereof.
**1.5. “Incompatible With Secondary Licenses”**
means
* **(a)** that the initial Contributor has attached the notice described
in Exhibit B to the Covered Software; or
* **(b)** that the Covered Software was made available under the terms of
version 1.1 or earlier of the License, but not also under the
terms of a Secondary License.
**1.6. “Executable Form”**
means any form of the work other than Source Code Form.
**1.7. “Larger Work”**
means a work that combines Covered Software with other material, in
a separate file or files, that is not Covered Software.
**1.8. “License”**
means this document.
**1.9. “Licensable”**
means having the right to grant, to the maximum extent possible,
whether at the time of the initial grant or subsequently, any and
all of the rights conveyed by this License.
**1.10. “Modifications”**
means any of the following:
* **(a)** any file in Source Code Form that results from an addition to,
deletion from, or modification of the contents of Covered
Software; or
* **(b)** any new file in Source Code Form that contains any Covered
Software.
**1.11. “Patent Claims” of a Contributor**
means any patent claim(s), including without limitation, method,
process, and apparatus claims, in any patent Licensable by such
Contributor that would be infringed, but for the grant of the
License, by the making, using, selling, offering for sale, having
made, import, or transfer of either its Contributions or its
Contributor Version.
**1.12. “Secondary License”**
means either the GNU General Public License, Version 2.0, the GNU
Lesser General Public License, Version 2.1, the GNU Affero General
Public License, Version 3.0, or any later versions of those
licenses.
**1.13. “Source Code Form”**
means the form of the work preferred for making modifications.
**1.14. “You” (or “Your”)**
means an individual or a legal entity exercising rights under this
License. For legal entities, “You” includes any entity that
controls, is controlled by, or is under common control with You. For
purposes of this definition, “control” means **(a)** the power, direct
or indirect, to cause the direction or management of such entity,
whether by contract or otherwise, or **(b)** ownership of more than
fifty percent (50%) of the outstanding shares or beneficial
ownership of such entity.
### 2. License Grants and Conditions
#### 2.1. Grants
Each Contributor hereby grants You a world-wide, royalty-free,
non-exclusive license:
* **(a)** under intellectual property rights (other than patent or trademark)
Licensable by such Contributor to use, reproduce, make available,
modify, display, perform, distribute, and otherwise exploit its
Contributions, either on an unmodified basis, with Modifications, or
as part of a Larger Work; and
* **(b)** under Patent Claims of such Contributor to make, use, sell, offer
for sale, have made, import, and otherwise transfer either its
Contributions or its Contributor Version.
#### 2.2. Effective Date
The licenses granted in Section 2.1 with respect to any Contribution
become effective for each Contribution on the date the Contributor first
distributes such Contribution.
#### 2.3. Limitations on Grant Scope
The licenses granted in this Section 2 are the only rights granted under
this License. No additional rights or licenses will be implied from the
distribution or licensing of Covered Software under this License.
Notwithstanding Section 2.1(b) above, no patent license is granted by a
Contributor:
* **(a)** for any code that a Contributor has removed from Covered Software;
or
* **(b)** for infringements caused by: **(i)** Your and any other third party's
modifications of Covered Software, or **(ii)** the combination of its
Contributions with other software (except as part of its Contributor
Version); or
* **(c)** under Patent Claims infringed by Covered Software in the absence of
its Contributions.
This License does not grant any rights in the trademarks, service marks,
or logos of any Contributor (except as may be necessary to comply with
the notice requirements in Section 3.4).
#### 2.4. Subsequent Licenses
No Contributor makes additional grants as a result of Your choice to
distribute the Covered Software under a subsequent version of this
License (see Section 10.2) or under the terms of a Secondary License (if
permitted under the terms of Section 3.3).
#### 2.5. Representation
Each Contributor represents that the Contributor believes its
Contributions are its original creation(s) or it has sufficient rights
to grant the rights to its Contributions conveyed by this License.
#### 2.6. Fair Use
This License is not intended to limit any rights You have under
applicable copyright doctrines of fair use, fair dealing, or other
equivalents.
#### 2.7. Conditions
Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted
in Section 2.1.
### 3. Responsibilities
#### 3.1. Distribution of Source Form
All distribution of Covered Software in Source Code Form, including any
Modifications that You create or to which You contribute, must be under
the terms of this License. You must inform recipients that the Source
Code Form of the Covered Software is governed by the terms of this
License, and how they can obtain a copy of this License. You may not
attempt to alter or restrict the recipients' rights in the Source Code
Form.
#### 3.2. Distribution of Executable Form
If You distribute Covered Software in Executable Form then:
* **(a)** such Covered Software must also be made available in Source Code
Form, as described in Section 3.1, and You must inform recipients of
the Executable Form how they can obtain a copy of such Source Code
Form by reasonable means in a timely manner, at a charge no more
than the cost of distribution to the recipient; and
* **(b)** You may distribute such Executable Form under the terms of this
License, or sublicense it under different terms, provided that the
license for the Executable Form does not attempt to limit or alter
the recipients' rights in the Source Code Form under this License.
#### 3.3. Distribution of a Larger Work
You may create and distribute a Larger Work under terms of Your choice,
provided that You also comply with the requirements of this License for
the Covered Software. If the Larger Work is a combination of Covered
Software with a work governed by one or more Secondary Licenses, and the
Covered Software is not Incompatible With Secondary Licenses, this
License permits You to additionally distribute such Covered Software
under the terms of such Secondary License(s), so that the recipient of
the Larger Work may, at their option, further distribute the Covered
Software under the terms of either this License or such Secondary
License(s).
#### 3.4. Notices
You may not remove or alter the substance of any license notices
(including copyright notices, patent notices, disclaimers of warranty,
or limitations of liability) contained within the Source Code Form of
the Covered Software, except that You may alter any license notices to
the extent required to remedy known factual inaccuracies.
#### 3.5. Application of Additional Terms
You may choose to offer, and to charge a fee for, warranty, support,
indemnity or liability obligations to one or more recipients of Covered
Software. However, You may do so only on Your own behalf, and not on
behalf of any Contributor. You must make it absolutely clear that any
such warranty, support, indemnity, or liability obligation is offered by
You alone, and You hereby agree to indemnify every Contributor for any
liability incurred by such Contributor as a result of warranty, support,
indemnity or liability terms You offer. You may include additional
disclaimers of warranty and limitations of liability specific to any
jurisdiction.
### 4. Inability to Comply Due to Statute or Regulation
If it is impossible for You to comply with any of the terms of this
License with respect to some or all of the Covered Software due to
statute, judicial order, or regulation then You must: **(a)** comply with
the terms of this License to the maximum extent possible; and **(b)**
describe the limitations and the code they affect. Such description must
be placed in a text file included with all distributions of the Covered
Software under this License. Except to the extent prohibited by statute
or regulation, such description must be sufficiently detailed for a
recipient of ordinary skill to be able to understand it.
### 5. Termination
**5.1.** The rights granted under this License will terminate automatically
if You fail to comply with any of its terms. However, if You become
compliant, then the rights granted under this License from a particular
Contributor are reinstated **(a)** provisionally, unless and until such
Contributor explicitly and finally terminates Your grants, and **(b)** on an
ongoing basis, if such Contributor fails to notify You of the
non-compliance by some reasonable means prior to 60 days after You have
come back into compliance. Moreover, Your grants from a particular
Contributor are reinstated on an ongoing basis if such Contributor
notifies You of the non-compliance by some reasonable means, this is the
first time You have received notice of non-compliance with this License
from such Contributor, and You become compliant prior to 30 days after
Your receipt of the notice.
**5.2.** If You initiate litigation against any entity by asserting a patent
infringement claim (excluding declaratory judgment actions,
counter-claims, and cross-claims) alleging that a Contributor Version
directly or indirectly infringes any patent, then the rights granted to
You by any and all Contributors for the Covered Software under Section
2.1 of this License shall terminate.
**5.3.** In the event of termination under Sections 5.1 or 5.2 above, all
end user license agreements (excluding distributors and resellers) which
have been validly granted by You or Your distributors under this License
prior to termination shall survive termination.
### 6. Disclaimer of Warranty
> Covered Software is provided under this License on an “as is”
> basis, without warranty of any kind, either expressed, implied, or
> statutory, including, without limitation, warranties that the
> Covered Software is free of defects, merchantable, fit for a
> particular purpose or non-infringing. The entire risk as to the
> quality and performance of the Covered Software is with You.
> Should any Covered Software prove defective in any respect, You
> (not any Contributor) assume the cost of any necessary servicing,
> repair, or correction. This disclaimer of warranty constitutes an
> essential part of this License. No use of any Covered Software is
> authorized under this License except under this disclaimer.
### 7. Limitation of Liability
> Under no circumstances and under no legal theory, whether tort
> (including negligence), contract, or otherwise, shall any
> Contributor, or anyone who distributes Covered Software as
> permitted above, be liable to You for any direct, indirect,
> special, incidental, or consequential damages of any character
> including, without limitation, damages for lost profits, loss of
> goodwill, work stoppage, computer failure or malfunction, or any
> and all other commercial damages or losses, even if such party
> shall have been informed of the possibility of such damages. This
> limitation of liability shall not apply to liability for death or
> personal injury resulting from such party's negligence to the
> extent applicable law prohibits such limitation. Some
> jurisdictions do not allow the exclusion or limitation of
> incidental or consequential damages, so this exclusion and
> limitation may not apply to You.
### 8. Litigation
Any litigation relating to this License may be brought only in the
courts of a jurisdiction where the defendant maintains its principal
place of business and such litigation shall be governed by laws of that
jurisdiction, without reference to its conflict-of-law provisions.
Nothing in this Section shall prevent a party's ability to bring
cross-claims or counter-claims.
### 9. Miscellaneous
This License represents the complete agreement concerning the subject
matter hereof. If any provision of this License is held to be
unenforceable, such provision shall be reformed only to the extent
necessary to make it enforceable. Any law or regulation which provides
that the language of a contract shall be construed against the drafter
shall not be used to construe this License against a Contributor.
### 10. Versions of the License
#### 10.1. New Versions
Mozilla Foundation is the license steward. Except as provided in Section
10.3, no one other than the license steward has the right to modify or
publish new versions of this License. Each version will be given a
distinguishing version number.
#### 10.2. Effect of New Versions
You may distribute the Covered Software under the terms of the version
of the License under which You originally received the Covered Software,
or under the terms of any subsequent version published by the license
steward.
#### 10.3. Modified Versions
If you create software not governed by this License, and you want to
create a new license for such software, you may create and use a
modified version of this License if you rename the license and remove
any references to the name of the license steward (except to note that
such modified license differs from this License).
#### 10.4. Distributing Source Code Form that is Incompatible With Secondary Licenses
If You choose to distribute Source Code Form that is Incompatible With
Secondary Licenses under the terms of this version of the License, the
notice described in Exhibit B of this License must be attached.
## Exhibit A - Source Code Form License Notice
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
If it is not possible or desirable to put the notice in a particular
file, then You may include the notice in a location (such as a LICENSE
file in a relevant directory) where a recipient would be likely to look
for such a notice.
You may add additional accurate notices of copyright ownership.
## Exhibit B - “Incompatible With Secondary Licenses” Notice
This Source Code Form is "Incompatible With Secondary Licenses", as
defined by the Mozilla Public License, v. 2.0.

View File

@ -0,0 +1,30 @@
# Chat API
## Commands
!init (hidden)
- if it exists run on open chat session, only in 1-to-1 chats.
!help
!settings
### Explicitly calling commands
DApps are namespaced with @dappname!command, which can be useful if same commands used by multiple bots are available, alternatively these can be used for commands when bot is not actually in the chat, ie @wallet!send
## Custom Keyboards
Parameters use custom keyboards (instead of types, we adapt our types to be keyboards themselves?)
Make our emoji/sticker market with this, otherwise accessible through commands
ie !init command with param that opens up a config
## Messages
- subscription to message feed
- api for sending messages, and setting things like "typing"
- not available in group
## Privacy
- by default does not receive all messages in group chat
- only commands and in 1-to-1

View File

@ -0,0 +1,60 @@
# Contact Sharing
basic idea is to hash the pair of phone numbers (me, other) so that there are many collisions and then publish this (plausible deniable, because of collisions). and the contact your friend out of band if there is a hash that could be a match (which it is most likely not).
General problem:
 - Data is readable by anyone
 - The problem is not so much, that the server must not learn the contacts, but  that
     - no one must learn them, while all data is public
Alice announces its connection with Bob by:
- calculating H(A_phone_number + B_phone_number)
- applying costly scrypt or PBKDF2 hashing to derive H'
- truncating H to a low number of bits H'', so that collisions are likely
- publicly registers its unique pubkey_alice_bob for  H''
Notes so far:
- rainbow tables of 10^10^2 size (i.e. all phone number combinations) are impractical
- calculating all combinations is prohibitively costly
- collisions of H allow plausible deniability
- Problem: an adversary can impersonate Alice, need spam protection (PoW) here
Bob wants to know if Alice is participating in the network:
- Bob calculates H(A_phone_number + B_phone_number)
- Bob generates H and H'
- for all matching entries for H (including the one generated by Alice)
 - Bob encrypts truncated H(mobile_bob) for pubkey_alice_bob
 - and sends the message to Alice inbox on the server
 - Alice loads and decrypts the message
 - Alice can match  truncated H(mobile_bob) in hear contact list with a very low false positive rate
 - if Alice thinks she knows Bob, she might reply out of band
Notes:
- Bob can still plausibly deny that he knows Alice
- Bob can still plausibly deny that he participates in the system
- add some proof of work or similar for spam protection
This is hard against:
- Leaking users contact lists
- An adversary with a hypothesis about a connection can learn bobs phone number though
Limitations:
- New users (Bob) wont see others directly
- Existing users (Alice) need to invite Bob
- Quite some computation and communication overhead
 - ~ 500 x 10 messages send
 - 2x key pairs to remember for each
The Difficulty Of Private Contact Discovery
https://whispersystems.org/blog/contact-discovery/
https://news.ycombinator.com/item?id=7007554
https://news.ycombinator.com/item?id=11288169
https://news.ycombinator.com/item?id=11289223
Lame solution which is prone to rainbow table attacks.
https://github.com/SilentCircle/contact-discovery

View File

@ -0,0 +1,27 @@
# Discover
This document describes the Discover feature of Status. Ethereum is its community, and with Discover we want to connect other Ethereum users with other Ethereum users - to trade and exchange ideas. Ultimately this will reduce transaction costs and increase the utility of ETH.
Discover is done through a users Status (hence the application name). This status is a 140 char sub-headline to a users profile which can be seen on [my profile](https://zpl.io/22nSfB), [user profile](https://zpl.io/CFBa8) and [discover](https://zpl.io/Z1p9XlV) screens.
A status is private and not shared with anyone except their immediate contacts, unless a **#hashtag** is introduced. These #hashtags are locally searchable on the discover screen.
The Discover application protocol is built ontop of Whisper, possibly utilising our messaging protocol and is implemented in [status-im/status-lib](https://github.com/status-im/status-lib/tree/master/src/cljs/status_im/protocol)
Periodically the client should request from it's contacts, a package of statuses that is an aggregate compilation of discoverable statuses (created using the specifications below), this package should contain no more than 100-500 statuses and the period in which the client requests the package is after when the user is back online and/or after waiting X hours has elapsed. Whisper penalizes larger payloads so we may have to chunk this. `140chars × 4bytes (utf-8) × 100 contacts = 54kb`
The 100 contacts the user decides to return is weighted by;
- the newest available information (latest status from that user),
- the most seen contact statuses by other contacts. (that user who has seen the same contact status from all his contacts)
- and actual interactions with contacts, favor contacts that the user has actually messaged themselves.
- if contact is online
The Discover screen then takes this aggregate search space
`100-500 statuses × users in contact list` and organise them by #hashtags, the hashtags that have more than X contacts are put into the carousel under that #hastag category.
Below it the statuses are listed by most recent.
On tapping one of these messages a chat session is attempted with that user.
Each user should cache no more than 1000 statuses

View File

@ -0,0 +1 @@
# ERC20-to-Fiat Exchange

View File

@ -0,0 +1,35 @@
# Messaging
## Chat Protocol Test setup (out of date)
1. Start app in android
2. Build geth:
```
git clone https://github.com/status-im/go-ethereum
cd go-ethereum
git checkout develop
make geth
```
Alternatively on Mac it can be done by
```
brew tap ethereum/ethereum
brew install ethereum --devel
```
3. Connect to app geth console
```
adb forward tcp:8545 tcp:8545
build/bin/geth attach http://localhost:8545
```
4. Inside console:
```
admin.addPeer("enode://e2f28126720452aa82f7d3083e49e6b3945502cb94d9750a15e27ee310eed6991618199f878e5fbc7dfa0e20f0af9554b41f491dc8f1dbae8f0f2d37a3a613aa@139.162.13.89:55555")
```
5. After 10 seconds you should see the peer in:
`admin.peers`

View File

@ -0,0 +1 @@
# Moments

View File

@ -0,0 +1 @@
# Sticker Market

View File

@ -0,0 +1 @@
# Visual Programming

View File

@ -1 +1,38 @@
site_name: My Docs
site_name: Status Wiki
# site_url: https://wiki.status.im
# repo_url: https://github.com/status-im/wiki.status.im/
site_description: 'Everything you need to know about Status, a messenger and browser for Ethereum'
google_analytics: ['UA-79146816-1', 'wiki.status.im']
pages:
- Welcome: index.md
- Getting Started:
- Mission & Core Values : 'getting-started/mission-and-core-values.md'
- FAQ: 'getting-started/faq.md'
- Code of Conduct: 'getting-started/code-of-conduct.md'
- Contributing:
- Developers:
- Building Status: 'contributing/development/building-status.md'
- Adding DApps: 'contributing/development/adding-dapps.md'
- Clojurescript: 'contributing/development/clojurescript.md'
- Golang: 'contributing/development/golang.md'
- UX & Design: 'contributing/ux-and-design.md'
- Testing & Feedback: 'contributing/testing-and-feedback.md'
- Documenting: 'contributing/documenting.md'
- Marketing: 'contributing/marketing.md'
- Community:
- Slack: 'community/slack.md'
- Newsletter: 'community/newsletter.md'
- Blog: 'community/blog.md'
- Tell a Friend: 'community/tell-a-friend.md'
- Specifications:
- Contact Sharing (WIP): 'specifications/contact-sharing.md'
- Chat API (WIP): 'specifications/chat-api.md'
- Discover (WIP): 'specifications/discover.md'
- Status Messaging (WIP): 'specifications/messaging.md'
- Exchange (WIP): 'specifications/erc20-exchange.md'
- Sticker Market (WIP): 'specifications/sticker-market.md'
- Visual Programming (WIP): 'specifications/visual-programming.md'
- Moments (WIP): 'specifications/moments.md'
- License:
- MPL2: 'licenses/mpl2.md'
- LGPLv3-static: 'licenses/lgpl-v3.0-static.md'