Nym Transfer: A Private, Secure File-Sharing Platform Built on Nym Mixnet

🪻 Nym Squad League Proposals
1

NymTransferLogo
NymTransferLogo357×112 2.77 KB

:lock: NymTransfer A Privacy-First File Sharing Platform

:bulb: Overview

:o: Purpose of the Project

NymTransfer aims to create a user-friendly, privacy-focused file-sharing platform powered by the Nym Mixnet infrastructure. By integrating Nym’s decentralized technology, NymTransfer ensures end-to-end traffic privacy, protecting both user data and metadata throughout the entire file-sharing process.

Inspired by the simplicity of platforms like WeTransfer, NymTransfer preserves the convenience users expect while embedding robust privacy features at its core. As a result, it aligns closely with the mission of the Nym Innovation Fund to support real-world applications that showcase Nym’s unique capacity to safeguard online interactions.

:dart: Stepping Stone to a Bigger Vision

While file sharing is an immediate, practical use case, NymTransfer also serves as a stepping stone toward creating more advanced services on the Nym network. By starting with a WeTransfer-style platform—which can be built more quickly—we gain direct experience with the Nym Mixnet and learn how to fully utilize its privacy features.

This knowledge will set the stage for future offerings, such as NymDrop or NymDrive, that provide Dropbox-like functionality with the added benefit of a secure, privacy-first design powered by Nym.

:coin: Funding Request

NymTransfer is a privacy-focused file-sharing platform leveraging Nym Mixnet technology to ensure robust anonymity and confidentiality throughout the file transfer process.

Overview

Project: NymTransfer
Milestone: :1st_place_medal: First Milestone

With this proposal, we request 120,000 NYM to cover critical expenses for achieving our first milestone, which focuses on delivering:

  • A stable backend infrastructure
  • A user-friendly frontend
  • Strong initial development to create the foundation for NymTransfer’s core functionalities

:building_construction: Milestone 1: Scope & Deliverables

:wrench: Backend Development & Hosting

  • Dedicated Server: Approximately 1,600 NYM/month, ensuring robust performance for concurrent uploads and downloads.
  • Mixnet Integration: Seamless routing of all network packages through Nym’s Mixnet, providing maximum privacy and improved speed.

:computer: Frontend Development & Hosting

  • Dedicated Frontend Server: Approximately 800 NYM/month to ensure reliability and scalability for user-facing services.
  • UI/UX Enhancements: Collaboration with a dedicated UI/UX designer to improve the user experience, focusing on intuitive workflows for file uploads, link generation, and sharing.

:art: Sneak Peek of UI Design

Here’s a preview of the user interface design for NymTransfer, showcasing the focus on simplicity, usability, and privacy:

Screenshot 2025-01-22 at 22.02.43
Screenshot 2025-01-22 at 22.02.431908×1004 25.8 KB

:hammer: Core Development

Total Development Cost: 75,000 NYM

The core development focuses on building essential features for NymTransfer, ensuring privacy, efficiency, and scalability:

:one:. File Upload: Develop secure and private workflows for uploading files through the Nym Mixnet.
:two:. File Download: Implement seamless and private file downloads with robust error handling.
:three:. Encrypted Link Generation: Create secure, time-restricted links for file access.
:four:. Enhanced File Management: Add features for managing files, including deletion and metadata protection.
:six:. Tech Debt Resolution: Address technical debt for long-term platform stability.
:seven:. Testing: Perform integration and performance tests to validate workflows and ensure reliability.

:framed_picture: Infrastructure Diagram

Infrastructure Diagram
Infrastructure Diagram1914×389 23.6 KB

:art: Design Partnership

  • UI/UX Designer: 10,000 NYM to create a polished, professional interface that streamlines workflows and enhances user satisfaction.

:bank: Unexpected Vault

  • Contingency Fund: Allocating 5%–10% of the total funds (6,000–12,000 NYM) for unforeseen development costs, including:
    • Additional security audits
    • Operational expansions
    • Unexpected technical challenges

:moneybag: Total Request: 120,000 NYM

This funding will enable the successful completion of the first milestone, establishing the foundation for a secure, user-friendly, and privacy-first file-sharing platform powered by Nym’s Mixnet technology.

:bowing_man: Team

Amorf
  • Role & Background: Early supporter of Nym since the 2020 incentivized testnet, and a software developer actively collaborating with Hoodrun since 2022.
  • Notable Work: Contributions include developing various Web3 tools, indexers, cosmos explorers, and Telegram bots. Maintains a strong focus on privacy technologies and open-source ecosystems.
  • GitHub: github.com/amorfc
Errorist
  • Role & Background: Tech Lead at Hoodrun with deep expertise in cutting-edge technologies.
  • Notable Work: Oversees development of advanced Web3 solutions, blockchain indexers, and high-performance architectures. Plays a key role in product vision and technical direction.
  • GitHub: github.com/Errorist79
Onur
  • Role & Background: Senior Backend Developer and music producer, passionate about open-source projects.
  • Notable Work: Dedicated to building robust, scalable backend systems and ensuring best software practices. Champions seamless integrations and efficient system performance.
  • GitHub: github.com/onurkybsi

Together, we have a full range of technical and operational capabilities to develop, scale, and maintain our privacy-centric file-sharing application using Nym’s infrastructure. Our combined experience in privacy tech, Web3, and backend development allows us to deliver a secure, high-performance solution. Each of us is committed to open-source principles, and we believe this project will significantly contribute to Nym’s ecosystem.

If there is any additional information or further clarifications required about our team, we will be glad to provide them.

:chart_with_upwards_trend: Future Plans

Currently, NymTransfer operates without an authentication mechanism, as traditional Web2 structures contradict our privacy-first philosophy. However, this presents challenges in monetizing the platform effectively. To address this, we propose:

  • File Size and Type Restrictions: Limiting file sizes to 1GB initially and potentially restricting certain file types (e.g., restricting extensions like .txt) to manage bandwidth and storage costs effectively.
  • Wallet-Based Authentication: Exploring authentication via Cosmos wallets or other blockchain wallets that ensure metadata privacy. This approach allows users to pay for bandwidth or additional storage without compromising privacy.

We believe these ideas should be further discussed and refined with input from the community and the Nym team to align with our shared vision for a privacy-focused future.

:trophy: Why NymTransfer?

Feature WeTransfer Firefox Send NymTransfer
Metadata Privacy :x: :x: :white_check_mark: (Nym Mixnet)
E2EE :x: :white_check_mark: :white_check_mark: + decentralized storage (Milestone 2)
Censorship Resistance :x: :x: :white_check_mark: (IPFS/Filecoin) (Milestone 2/3)

We’re excited to contribute to the NYM ecosystem by building a user-friendly, privacy-focused public good service. We welcome feedback and ideas from the community—not just for Milestone 1, but for all future milestones.

Thank you for reviewing our proposal. Your insights will help us create a platform that truly embodies NYM’s mission.

The NymTransfer Team

9 Likes
2

Great job! Well done!

1 Like
3

Hey @Amorf this is looking great, happy to see this moving forward!

Some technical questions/points

  • Glad to see you got the TcpProxy working on the frontend as well - is this (in the current version of the code) going to be run separately or used as a library as part of the main UI process? I presume it will be a standalone desktop app? Or are you routing browser traffic to the localhost port exposed by the TcpProxyClient?

  • One thing that we’re working on with some new protocol work is to be able to essentially have the standard client be able to concurrently stream, at some point this hopefully will be properly integrated into the TS SDK client as well, which would allow for running concurrent client requests from the browser. This will take a bit of work on our side but just to let you know about this possibility. This is currently in the R&D stage but interested to hear your thoughts / requirements.

  • Is the code public anywhere to try out?

  • How are you planning to do file retrieval? By something like a CID which is shared out of band from the main app? Or are you thinking of having some sort of file discovery further down the line?

Let me know if you want to chat about it either in this channel or the dev channel on Matrix. :slight_smile:

4

A few more:

  • Out of interest, what sort of files have you managed to send/retrieve with this? Would be interested to know rough timings for upload/download with different sized files

  • Also if you’ve got even ballpark numbers on the amount of e.g. concurrent requests and sessions that are flying about when doing so I would be very interested to see them!

5

I would maybe check out the possibilities opened up by Penumbra if you’re looking for Cosmos compatible transfers.

I suppose this opens up a question regarding whether you allow for a ‘free tier’ usage: if so, you might want to decouple Auth from a wallet, and have the option to ‘Pay to Store’ via Wallet (and use the Auth there) or have a local-first Auth of some kind (keypair generation on local machine maybe). The second option becomes a little more tricky depending on whether you want to aim to have this as a desktop or browser based interface though, but would be happy to hear thoughts on it.

6

As you already know, TcpProxyClient is not suitable for pure web applications. Since we’re not developing a desktop application, we’re essentially constrained by the issue in the WASM client. Therefore, we’ve only used TcpProxyClient as a proof of concept. Once the WASM client issue is resolved, we can immediately switch to the WASM client because the implementation is already in place.

7

That sounds awesome! Having a concurrent client is exactly what is needed. We’re excited to hear more about this. Is it going to be a replacement for WASM or not?

8

We plan to use a blob storage solution (e.g., AWS S3, Azure Blob Storage) for file retrieval, but we’re also open to exploring IPFS or other decentralized options. Please let us know if there are any limitations or considerations we should be aware of.

9

I will share some metrics soon :+1:

10

We plan to integrate wallet-based authentication for paid storage, but for the free tier, there’s no need for wallet integration. This tier will have a small file-size limit; if users need to exceed this limit, they can switch to the paid option.

11

Hey @max-nym here is the repo you can follow the instructions.

1 Like
12

I would suggest looking at either IPFS or maybe Codex from the offset, since you can run a node with no identifying information there, so your app would be far more private from the offset!

1 Like
13

This tier will have a small file-size limit; if users need to exceed this limit, they can switch to the paid option.

Size-limit is a good idea for initial free-tier, nice

1 Like
14

The underlying Client (which in the case of TS SDK is compiled to WASM) should be able to deal with concurrency, so not a replacement more a modification of the underlying Client / interface.

Thinking more about this; this is a good approach initially so you don’t have to overengineer a total Sybil defense from the beginning. Having some sort of access control to gate storage amounts is also something that, in the future, would be able to be theoretically done anonymously via some sort of Service Credential (a modified version of the bandwidth-gating zk-nyms that we’re going to be using for the NymVPN).

I think the size of allowances you can be thinking of is also reliant on what storage architecture you’re looking at using; for something like IPFS, all you’re paying for is whatever pinning service or VPS infrastructure you’re running your IPFS node(s) on, vs having to pay something like S3 charges. Also fundamentally since you’re already using something like Nym for network level traffic privacy, I think it makes more sense to use something like IPFS which you run as a service rather than piping the stored files into a centralised service. Also its a great selling point to be piping data via the Mixnet to decentralised storage!

One minor point regarding using wallets as Auth: that is a potential vector for creation of a fingerprint for the service you run to see, even if you’re using something like IPFS, so be careful with what you’re sending / how your service might be able to work out on the application level (i.e. when the traffic has come through the Mixnet to your backend) whether its the same person requesting files over time.

15

Hey Max, I’ve just implemented a benchmark page, tested it, and shared a demo at the link below. It provides request metrics on the NYM Mixnet, allowing you to test and track performance for all upload, download, and file-metadata requests. Please follow the instructions here to get started.

1 Like
16

Thanks for the link and sorry for the late reply, the last few weeks have been crunching on the NymVPN launch so I’m a little behind on replies!

1 Like
17

Can you later add support for different request types such as the ones for http/s web downloads or magnet links and can be combined with lets say a port forwarding proxy or tor and or i2p or for example so users who don’t want to download privately don’t have to and so it can be better integrated into software with existing user bases without having to host multiple instances of the same file

And a side note nym should have port forwarding and it’s not uncommon among existing vpns and would seriously boost the competitionality of nym vpn