157 views
 owned this note
# NLnet Funding Submission Proposal ## Please select a call * Thematic call: User Operated Internet Fund ## Contact information * Your name (max. 100 characters): James Mills * Email address: prologic@shortcircuit.net.au * Phone numbers: +61483894152 * Organisation (max. 100 characters): * Country: Australia ## General project information * Project Name: Salty IM * Website: https://salty.im/ Abstract: Can you explain the **whole project** and its expected outcome(s). > Salty IM is a decentralised e2e encrypted messaging protocol inspired by the IndieWeb and the Twtxt text format for microblogging. > > Salty IM has a very clear and simple specification that can be found at https://salty.im/spec.html -- The original proof-of-concept was implemented in a POSIX Shell script. Saltpack from Keybase is used as the message encoding format which along with borrowed code from Keys.pub uses Ed25519 public key cryptography. > > Salty IM has a reference client in the form of a CLI and TUI as well as a reference Broker (server). > > We (several of us work on this in our spare time) want to further the development of the project by building a great reference mobile client reusing our Go client as a Flutter plugin with the User Experience you'd expect from something like Signal. Unlike Signal however, users do not require a phone number and Salty IM goes to great lengths to ensure no personal identifiable information is ever stored or leaked. > > As a bonus we would also like to improve the reference broker (`saltyd`) and provide a number of instances geographically around the world for users to freely use. Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions? > Not specifically in the space of cryptographic applications, however I have developed, written and deployed many open source projects such as: > - Bitcask -- ๐Ÿ”‘ A high performance Key/Value store written in Go with a predictable read/write performance and high throughput. Uses a Bitcask on-disk layout (LSM+WAL) similar to Riak. > - Yarn.social -- ๐Ÿ“• yarn is a Self-Hosted, Twitterโ„ข-like decentralised microblogging platform. No ads, no tracking, your content, your data! > - circuits -- An event-driven Python framework (built before Python3's asyncio) > - Tube -- ๐Ÿ“บ a Youtube-like (without censorship and features you don't need!) Video Sharing App written in Go which also supports automatic transcoding to MP4 H.265 AAC, multiple collections and RSS feed. > - go-gopher -- Gopher (RFC 1436) protocol library for the Go (Golang) programming language supporting both client and server > - golinks -- ๐ŸŒ A web app that allows you to create smart bookmarks, commands and aliases by pointing your web browser's default search engine at a running instance. Similar to bunny1 or yubnub. > - gopherproxy -- Gopher (RFC 1436) Web Proxy > - msgbus -- A real-time message bus server and library written in Go with strong consistency and reliability guarantees. > > I have also managed the development process of many open source projects with teams based world wide. ## Requested support * Requested Amount: $12,000 Euros Explain what the requested budget will be used for? Does the project have other funding sources, both past and present? (If you want, you can in addition attach a budget at the bottom of the form) > Working on a modest budget based on experience with developers from India, one of which I regularly work with, requires payment of between $1200 USD and $1500 USD per month. The budget of $12,000 Euros would approximately be broken down into: > > - 5x Engineering Months of development (India or similar) at ~$1200-1500 USD/month > - 5x instances of `saltyd` placed geographically around the globe at ~$10/month (high performance VMs) for 3 years. > > I expect (depending on development costs and hiring) a small budget of $2k-$4k to be left over to maintain the project, free instances, bug fixes and support for a number of years beyond the initial development of the mobile app and improvements to the `saltyd` reference Broker. **Compare** your own project with existing or historical efforts. > The only project I can really compare Salty IM to is Signal from the Signal Foundation (https://signal.org) > > Both Signal and Salty IM are designed to be privacy focused and encrypted from the client (e2e). Unlike Signal however, Salty IM **does not** require users to signup with a "phone number". This is one of the biggest bugbears amongst many types of users (security and privacy conscientious) as well as parents like myself who have young children who believe they are far too young to have open-ended phones with a phone number. > > Some other differences: > > - Signal operates in a centralised manner. Salty IM is decentralised. > - Signal uses triple-ratcheting (Signal protocol). Salty IM uses Saltpack and Ed25519 > > Finally Salty IM is designed to be simple. We have deliberately kept the specification simple, open and transparent and encourage the development and operation of competing clients and brokers. To date there is one other broker developed by a @xuu@sour.is What are significant technical **challenges** you expect to solve during the project, if any?) > The biggest technical challenge is building a great mobile UX (user experience) **and** reusing our existing Go code. Nobody on the development team (myself included) have great technical expertise in mobile app development or generally UI/UX. It is in the project's best interests to keep the reference client (as a library) and broker (server) implementations in a language (GO that is easy to understand and maintain for its correctness (not yet audited). Describe the **ecosystem** of the project, and how you will engage with relevant actors and promote the outcomes? > The ecosystem currently comprises a dozen folks from the technical community who actively were involved in aLpha testing the early versions of the reference client (originally written as a shell script). Currently there are two primary developers (myself prologic and xuu). There are two other folks who have attempted to build a mobile app, one using GIO and another using Go-App as a WASM. Both attempts were not successful in building a great experience. > > Once the project is successful in building a much better mobile app experience, there are numerous folks in my immediate local vicinity who young families and children that would benefit from using a secure, encrypted messaging app that doesn't require sign up to "big-tech" public cloud companies like Microsoft, Apple, Google or (worse) Facebook/Meta. > > Note that I have ignored any "marketing" here in the project's proposal as I am neither a marketer, not possess any such skills. I have access to a couple of people that _could_ potentially help with this (for free hopefully), however I also expect word-of-mouth to help grow a small community of enthusiasts interested in protecting their privacy and security and building experiences based on open decentralised protocols and not centralised platforms. ## Attachments Attachments: add any additional information about the project that may help us to gain more insight into the proposed effort, for instance a more detailed task description, a justification of costs or relevant endorsements. Attachments should only contain background information, please make sure that the proposal without attachments is self-contained and concise. Don't waste too much time on this. Really. > N/A ## How may we handle your information When your project gets selected, we will legally need to retain your information for compliance purposes for at least seven years. Also, in case you are submitting to one of the NGI related funds, at that point we will need to share some information with our (not-for-profit) partner organisations in order so they may assist you with mentoring as well as complementary services e.g. accessibility, documentation, localisation, packaging, etc. By submitting a proposal you grant us permission to handle the data in the proposal in the manner described. What should we do in the other case, e.g. when your project is not immediately selected? * I allow NLnet Foundation to keep the information I submit on record, should future funding opportunities arise * Send me a copy of this application.