New app: PrivacySafe
Abstract
Please introduce the functions and usage of your app in summary, and also attach some screenshots.
PrivacySafe is a secure and private platform that user owns. The first screen, a startup app/component allows user to connect and use existing 3NWeb service account, or to signup to existing service from IvyCyber, or to supply signup link to any other 3NWeb service. When user signs in, platform installs into their space a set of everyday 3NWeb apps: chat, contacts, treasure (passwords and other treasures' keeper). Apps synchronize their data relying on 3NWeb server, so that several devices can be used, like phone and desktop ( https://download.privacysafe.app/ ).
(screenshots from CalyxOS)
When a signup link (instruction to setup own server at https://github.com/PrivacySafe/3nweb-service ) is used for a different provider, startup app continues similarly, but now serving from different domain
After login:
(screenshots from samsung phone)
Dashboard with 3NWeb apps that cover respective user needs:
Users do different activities: chat, contacts, etc.
Chats with users from different domains/providers:
Video/audio calls, on a platform you own. Digital sovereignty ...
Contacts app. Again ability to talk with people from different domains.
There is no central place to dox people. Hence, contacts app provides convenient ways to pass friend's contacts, old-fashion way, from person to person:
User has control over keys and security:
Treasure app. Your password manager
Categories/groups of treasures:
And, of course, a desktop form factor of these apps, screenshot from linux mint. Again note different domains. And on desktop, windows have user ids displayed, when several identities are logged in. Say one for work, another for personal use, third one is a club, etc.
Users are not limited to single identity on 3NWeb.
Platform has a full security view, system map, viewable on desktop, of course:
Please elaborate why you wrote this app. Please highlight the unique functions it provides over other similar apps in F-Droid.
Platform app on Android hold/provides for user experience. UX/UI we can talk a lot. Yet, it is a visible top of a sovereign tech we look for.
3NWeb - No unencrypted data on servers, No unnecessary metadata to servers, Nothing to abuse on server. When user installs a 3NWeb app into their space, server doesn't know, that user does it, and can't censor user. Web-style federation ensures that peers can always talk to each other, and they can choose different service providers, including using own server.
On screenshots there was chat, and we may compare it with Signal app. Can you give me code for Signal server for me to run on my domain and interoperate with others? I've been asking this a lot on past HOPE conference, no one can tell it is possible. Yet, it is possible with PrivacySafe and respective 3NWeb server. It is possible to federate, web-style, not classical style (SMTP, Matrix), and have modern convenient secure and private implementation.
Besides chat we provide Treasure app, a password manager. Let's note that installing password manager on NextCloud involves installing into server. With PrivacySafe server doesn't know you have and use Treasure, password manager. It means that home 3NWeb server is more safe at home, a place with low security, than likes of NextCloud's.
There is no permissions needed to create 3NWeb app, and to provide updates. Like the web, and unlike almost all stores on phones and desktops. Yet, platform runs apps' components in isolated runtimes, following capability model, providing security to end users, and ease of mind to developers.
This is how digital freedom looks like. A whole platform is needed to account for user's interests, utility (3NWeb) providers, and app developers perspectives. And, in a monopoly game our society finds itself today, providers should have competition ingrained into tech protocols.
Checklist
Policy
- The app complies with the inclusion criteria.
- The original app author has been notified (and does not oppose the inclusion). If you are not the author, please paste the link of the reply from the author.
- The upstream app source code repo contains the app metadata in a Fastlane or Triple-T folder structure. The summary and description must be included and images, icon, and changelog should also be provided for better user experience. The
en-USlocale must be included.
Docs
- Please read the guide first if this is your first contribution.
- Please make sure your metadata follows the best practice in our templates.
- Please read the Build Metadata Reference and make sure your metadata is valid.
- Please read the Quick Start Guide.
Merge Request Setup
- The title of this merge request should follow "New app: app name" format.
- Please make sure your fdroiddata fork is public and your branch is not protected. See https://docs.gitlab.com/user/project/repository/branches/protected/.
- Please read our Git guide if you don't know how to rebase your branch. Don't rebase your branch if there is no conflict.
- All related fdroiddata and RFP issues have been referenced in this merge request
- Please only submit one app in one MR.
Metadata
- Metadata must be put in
metadata/<applicationId>.yml. - Metadata must be a valid YAML file.
- Metadata must use LF as line ending.
- Don't add summary/description/changelog/images or anything that should be provided in upstream repo. Please check the Changes tab to make sure there is no other unrelated files added in the MR.
- Releases are tagged and auto update is enabled unless there is a special reason.
- There is an issue tracker and contact info of the author so that we can report bugs and contact the author.
- An AuthorName must be added. It doesn't need to be the real name.
- External repos are added as git submodules instead of srclibs. You can update git submodules without opening an MR in this repo and the submodule is covered by our scanner.
- Enable Reproducible Builds. We'll use your signature for improved security/reliability, also allowing users to switch between different channels. Do note that if you don't enable reproducible build then the apk will be signed with our key so you can't enable it later. If you can't enable this, please add the reasons here.
- Setup abi split if the APK is large and the splitted ones can be much smaller.
- Only the latest versions should be kept in the metadata before it's merged. If you update the metadata, please replace the old versions with the new ones.
- Don't add any disabled versions in the metadata.
- The
commitfield should be the full hash. Please don't use tag or branch in commit.
Pipeline
- All pipelines should pass.
- All warnings and errors in the Reports tab should be fixed or explained.
- F-Droid CI runners are under GitLab's FOSS program, so there's no need for you to pay for any CI time. If Gitlab starts asking for phone numbers or credit cards don't submit anything, just leave a note in the MR so we know we need to trigger the CI.















