nikivdev/privacy-respecting: A Curated List That Argues Instead of Just Linking
Curated List of Privacy Respecting Services and Software
At a glance
- What is it?
- This repository is a Markdown reading list of privacy-respecting services and software, paired with short justifications for leaving the mainstream options. It is useful as a starting point, not as an audit of the tools it names.
- Who is it for?
- Use this list if you want a fast, opinionated map of privacy-oriented alternatives and are willing to verify each entry yourself, because the repository supplies links and short reasons rather than audits. Do not use it as procurement evidence or as a security assessment of any named service.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 76 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the list is actually for
The README states the purpose directly: it covers 'various free services whose business models are to collect as much personal data about you as possible and alternatives you can use to them.' That framing sets the scope. This is not a directory of every privacy tool that exists, and it is not a comparison matrix with feature columns. It is a set of topics (search engines, social networks, messengers, cloud storage, VPN, hosting, email, operating systems, browsers, video sharing, AI assistants, maps and navigation) where each entry either names a service to move away from or a service to move toward.
The intended reader is someone who already accepts the premise and wants names. The README links to an article by the author for the underlying argument, which means the repository itself does not spend space re-arguing why data collection matters. That is a reasonable editorial choice for a list, and it keeps the file short enough to scan. It also means the list is only as good as the reader's willingness to click through.
The two-part structure: accusation, then alternative
Each topic section uses the same shape. First a block headed 'You are the product' lists the mainstream services with a short reason attached. Then a block headed 'Alternatives' lists the replacements, usually with a link to a privacy policy, a principles page, or source code.
The reasons given in the first block vary in weight. Some are ownership statements: Bing is 'Owned by Microsoft', Instagram is 'Owned by Facebook'. Others are links to external arguments, such as the Futurism piece attached to Google or the blog post attached to Facebook. This is where the list is thinnest. Ownership is a fact, but it is not by itself an argument about data handling, and the reader who wants the argument has to leave the repository to find it.
The alternatives block carries more information density. Entries frequently pair a service with its source code, which is the most useful single field in the whole file. DuckDuckGo, Startpage, Brave Search, Searx, SearXNG, Librengine and Mojeek appear under search, with SearXNG described as a 'Fork of SearX' linking to its documentation. The pattern repeats across sections: Session is described as minimising sensitive metadata and not requiring a phone number, Element is tied to the Matrix protocol, Briar is peer-to-peer, Conversations is built on XMPP/Jabber.
Front-ends are the most concrete contribution
The 'Private front-ends' subsection under Social Networks is the part of the list with the clearest technical story. It names Invidious, Piped, Nitter, Libreddit, Teddit, Bibliogram and Beatbump, each with a link to its code repository. The mechanism these share is that they sit between you and the original service, serving the same content through a different interface, so the original service sees the front-end rather than your browser.
That is the one place in the README where the reader can infer how a category of tool works from the descriptions alone. Everywhere else the list assumes you know what a federated instance is or what running your own XMPP server involves. Worth noting: a front-end is only as private as the instance operator. A public Nitter or Invidious instance is run by someone, and the README does not discuss that dependency. If you care about the threat model, self-hosting the front-end is the version that matches the list's intent, and the code links are what make that possible.
The Messengers section shows the list's judgement, and its inconsistency
Messengers is the longest section and the only one with a third bucket, labelled 'Questionable'. Keybase is placed there because its backend is not open source and because it 'got merged with Zoom'. Telegram is placed there because group channels cannot be end-to-end encrypted. WhatsApp is listed under 'You are the product' with a more nuanced note than most: it uses the Signal Protocol so chats are encrypted, but it sends the user's contact book to Facebook servers.
That WhatsApp entry is the best writing in the file. It separates the encryption claim from the metadata claim instead of treating 'owned by Facebook' as sufficient. The problem is that this level of care is not applied uniformly. Under Alternatives, Wire is described as 'Open-source Projet based on End-to-end encryption (server in Switzerland)', which is a location claim, not a protocol claim, and the two are not the same thing. Wickr is described as 'Trusted By Millions Worldwide', which is marketing language copied from the vendor and tells the reader nothing about how it works. A list that can write the WhatsApp entry can write better entries for Wickr and Wire, and the fact that it does not is a sign of how much of this file is link collection rather than review.
Getting it into your workflow: there is nothing to install
There is no build step, no package, no configuration. The repository is a Markdown file plus a contribution guide. The practical commands are the ones you would use for any Git repository:
git clone https://github.com/nikivdev/privacy-respecting
The README instructs contributors to read contributing.md before opening a change, and the badge at the top links to a separate curated-lists repository. There are no releases retrieved for this repository, which is consistent with its nature: it is a document, not a versioned artifact. If you want to consume it, you read it on GitHub or clone it and read it locally. If you want to change it, the path is a pull request against the master branch, following whatever contributing.md specifies.
That is the entire operational surface. Anyone evaluating this as a software project will find no code to evaluate. The correct mental model is a maintained document with a review process, and the maintenance cost falls on whoever volunteers to keep the links alive.
Link rot, dead projects, and the maintenance problem
A curated list has one dominant failure mode and this one is exposed to it: entries go stale. Bibliogram, for example, is a known case of a front-end project that stopped operating, and a list that points readers at it without a status note sends them to a dead end. The README as supplied carries no last-verified dates, no deprecation markers, and no indication of when any entry was last checked.
The repository shows a recent push date, so someone is touching it, but a push can be a single link fix and tells you nothing about how much of the file has been reviewed. There is also no separation between a project that is actively maintained and one that was published once. For a reader deciding where to move their email or their messages, that distinction is the whole decision.
The mitigation is on the reader's side: treat every entry as a lead, then open the linked repository and check its own activity. The list gives you the name and the code link, which is exactly enough to do that check, and nothing more.
How it compares to a self-hosting catalogue like Awesome Selfhosted
The obvious alternative is a self-hosting catalogue, and the difference in approach is structural rather than a matter of quality. A catalogue like Awesome Selfhosted organises by what you can run on your own hardware and typically includes deployment notes, language, and licence fields. This list organises by what you are trying to replace, and its unit of value is the pairing of a service to leave with a service to adopt.
That makes the two complementary rather than competing. If you already know you want to stop using a given product, this list answers 'what else is there'. If you already know you want to run something yourself, a self-hosting catalogue answers 'what can I deploy and how'. This repository does cover self-hosted options in places (SearXNG, Prosody for running your own XMPP service, Pleroma as a federated server), but it does not carry the operational detail a deployment-focused catalogue would.
There is also a category this list includes that a self-hosting catalogue would not: hosted services like DuckDuckGo, Startpage and Mojeek, which you cannot run yourself. The list mixes hosted and self-hostable options in the same block without marking which is which, and that is a real usability gap for anyone whose reason for being here is to reduce reliance on third parties.
Licence and contribution terms
The repository metadata supplied does not include a licence, and the README does not state one. That matters if you intend to reuse the list, mirror it, or fold it into your own documentation. Without a licence file, the default position is that no reuse rights have been granted, regardless of how permissive the project feels. The README does link a contribution guide, so the process for submitting changes is documented even though the terms for redistributing the content are not. If reuse matters to you, check the repository for a licence file before copying anything out of it, and if there is none, ask the maintainer rather than assuming. Nothing here is legal advice; it is a pointer to an unresolved question in the material.
Editorial conclusion
Use this list if you want a fast, opinionated map of privacy-oriented alternatives and are willing to verify each entry yourself, because the repository supplies links and short reasons rather than audits. Do not use it as procurement evidence or as a security assessment of any named service. Before adopting anything from it, check the linked project's own repository and licence, and confirm whether the hosted instance you plan to use is run by the project or by a third party; the README itself does not distinguish between the two.
Community notes