Some of these features will be implemented like described here. Some will be changed because dreams and reality are not the same. Some may not be implemented at all. But as I get ideas for new features, I will add them to this page. And if other people contact me with some ideas that I like, I will also add them to this page. So this is the repository of feature ideas.
Bio
The bio feature should work like the bio in social applications like Telegram, Matrix and Nostr.
But unlike like Matrix, the bio should be able to give peope some information about the you.
I want to allow more text than what's usually allowed and optinal markdown formatting (no HTML) including links. The availability of the bio is decided in settings, so you can say that nobody can see your bio (for example while you're making it, before you decide if it's a good idea). Then you can make it available for your approved contacts or you can make it available for everyone.
If the bio is available for everyone, it means that people can watch your bio before they have sent a connection request to you. The Avatar will have similar settings, making it available in your bio or for everyone. If you restrict that, but open the bio, people will be able to see your text and your links and the information you have in the bio, but they will not be able to see your Avatar.
Here’s a cleaned-up version that keeps the original ideas but makes them read more like a feature specification for the DarkSpeak wishlist.
Dark Cables
Dark Cables are DarkSpeak’s decentralized equivalent of what were formerly known as tweets: short public messages that can spread through the network without relying on a central server or backend.
Decentralized distribution
Dark Cables must work entirely peer-to-peer. At least initially, each DarkSpeak client could store the cables it encounters and propagate them to its contacts.
The exact distribution protocol still needs to be designed, but it could work somewhat like Usenet: every client acts as both a reader and a small server. When two users connect, their clients can exchange information about the cables they have seen and pass along cables that the other client does not yet have.
Propagation should probably be limited to a certain distance from the original sender; perhaps three, four, or five hops, to prevent every client from eventually having to store the entire network.
This means there may be disconnected parts of the DarkSpeak network whose cables never reach each other. That is acceptable. In practice, people with overlapping interests are likely to develop overlapping contact networks, allowing relevant cables to propagate between them.
Attachments and tags
Cables should support small attachments, particularly images, but not arbitrary large files. Large attachments would make peer-to-peer replication prohibitively expensive.
Cables should also support tags. Because there is no central server, there cannot be a centralized feed algorithm. Instead, each client will construct the user's feed locally from the cables it knows about. Tags, contacts, interactions, and other locally available information could eventually be used to determine which cables are shown and how they are ranked.
Spam, abuse, and illegal material
A decentralized public message system also needs a way to deal with spam, abuse, and illegal material without introducing a central moderation authority.
Users must be able to block both individual accounts and the peers that repeatedly relay unwanted material. Reputation could potentially emerge from this behavior.
For example, a spammer might create 1,000 automated accounts but have only three accounts with genuine connections into the wider network. Those three accounts become the bridges through which the spam propagates. If users can identify that large amounts of blocked or unwanted material consistently arrive through those relays, their clients can stop accepting material from them.
In this model, filtering happens at the edges of the network rather than through a central authority. The details need considerably more thought, but resistance to spam and malicious flooding needs to be part of the protocol design from the beginning.
Why Dark Cables matter
Building this without central servers or central authority creates significant technical challenges, but Dark Cables are an essential DarkSpeak feature.
They give users a way to publicly announce what they are doing, share information beyond their immediate contacts, discover people with similar interests, and make themselves discoverable to potential future contacts. All while preserving DarkSpeak's decentralized architecture.
Local file server and exchange
A long time ago, I wrote an FTP server called WarFTP, which became quite popular in certain circles, for example, warez and shareware communities where people exchanged files.
Some people simply want to share what they have, which is fine. File sharing in DarkSpeak will allow you to share directories with other people. They will be able to browse a shared directory, see thumbnails of the files, and download whatever they like.
If you enable exchange for a folder and its subfolders, then in order to download something from you, users will also have to give you something in return. They can upload files, and based on either the size or number of files they upload - the rules will be flexible - they will automatically earn the ability to download a corresponding amount of content from your share.
The file-sharing and exchange system will also support lists of SHA-256 checksums to prevent people from uploading files you already have. Every file you make available will automatically be indexed by its checksum and blocked from being uploaded again. If somebody has the same file under a different name, they still won't be able to upload it. They have to provide files you don't already have. You will also be able to add checksums for files that you are simply not interested in.
When you look at files offered from another user, you can hide or mark files that's in your own checksum-list. That make it easy to look for something you don't already have.
Permissions can be configured for individual contacts. Some people can participate in a fully automatic exchange, while others can be given full access without having to exchange anything. They can download whatever they want and upload whatever they want.
People you don't know yet can also be allowed to upload, but with a quota - for example, 100 MB, or whatever limit you choose. You can then review and approve what they upload. This lets you verify that they aren't just uploading garbage, such as a file filled with random data and claiming that it's a Gutenberg book or a work by Aristotle.
This gives you the opportunity to build your own small community for sharing files and information. New people can begin with a very small upload quota. As you develop trust in them, you can increase that quota while still requiring approval of uploaded files. Eventually, you can remove the quota entirely, limited only by the available space on the file system. At the highest level of trust, you can enable a fully automatic exchange.
Basically, it's a replacement for the good old FTP model, but this time with anonymity built in and integrated into an application that also provides instant messaging.
Library
The Library feature is intended for people who want to build and maintain a collection of files for a shared purpose. A library is created by one person, the admin. The admin can give and revoke admin permissions to other users. The admins can add or revoke moderator permissions. All admins and moderators can add, delete and modify files in the library. They can also give other users access to upload files to the library, with or without approval from a moderator. All users who know the address to the library can download.
One possible use case would be a community interested in preserving historical material. For example, I can imagine a gay community collecting books, magazines, documents, and other material from gay communities of the 1960s, 1970s, and 1980s, bringing those materials together in one place and preserving them for the future.
To support something like this, the Library needs a distributed file system in which everyone who joins can optionally contribute storage space. You wouldn't have to store the entire library. For example, if I joined a library dedicated to creating a complete archive of a large publicly available collection like the Epstein Files, I might decide to contribute 2 GB of local storage. Up to 2 GB of data belonging to that library could then be stored on my disk.
The locally stored data would, of course, be fully encrypted. Individual blocks could be identified by checksums, while a file itself could be represented as a sequence of those block checksums.
When somebody downloads a file from the library, the system should work somewhat like BitTorrent. Rather than downloading the entire file from a single machine, it should retrieve different blocks from different machines wherever possible. This prevents a single participant from having to provide all of the bandwidth for a download.
To accomplish this, the system first needs to determine which blocks make up the requested file, identify which participating machines currently have those blocks, and then distribute requests across the available machines. Different blocks can be downloaded simultaneously from different sources and reassembled locally into the original file. This is a common approach in distributed systems; technologies such as Freenet and BitTorrent use related concepts.
There is an inherent weakness in this model. If people lose interest in a library, disconnect their machines, or stop contributing storage, some files may eventually become unavailable. In that sense, a distributed library is somewhat fragile. Nevertheless, it provides a useful best-effort approach to preserving and distributing collections without requiring a dedicated central server.
People who are particularly interested in preserving a library should also have the option of maintaining a complete local copy. If you have sufficient disk capacity - for example, a large conventional hard drive in a PC or home server - you could dedicate enough storage to hold the entire library. That would mean that even if many other participating machines went offline, you and people able to connect to you could still access the complete collection.
Unlike the File Sharing and Exchange feature, however, the Library is not conditional. There is no exchange ratio and no requirement that someone contribute files or storage before downloading. People who want to contribute can contribute; people who only want to download can simply download.
The Library is fundamentally a best-effort community preservation system: a way for a group of people to collaboratively create, maintain, preserve, and distribute a collection of related files that has value to their community.
And that community - and the material it chooses to preserve - could be anything.
Attached devices
Allow the user to have multiple devices attached to their id.
Groups and channels
Social media like experience where people can build community around an ide, a product or an interest.
Live streaming
One feature I really want to experiment with in DarkSpeak is live streaming - both peer-to-peer streaming between two people and streaming within small groups.
People familiar with RTP, the protocol commonly used for real-time audio and video, will probably say this can't work. RTP normally uses UDP and is designed to tolerate packet loss. If there isn't enough bandwidth to maintain a stream, packets can simply be dropped. You have probably experienced this during voice or video calls: there is a brief distortion or interruption, and then the conversation continues. Some of the data simply didn't arrive in time.
However, I previously worked for a company that developed an audio- and video-conferencing product similar to Zoom. One of the features I implemented was real-time streaming over TCP. The reason was practical. Many companies wanted to use conferencing software, but their IT departments maintained very restrictive firewalls and didn't want to open the ports normally required by real-time communication protocols. HTTPS/TLS traffic, on the other hand, was generally permitted. I was therefore tasked with making our conferencing traffic work over an ordinary TLS connection.
We used the WebRTC audio stack together with a proprietary video stack. I built a multiplexing protocol somewhat conceptually similar to HTTP/2, allowing multiple logical streams to travel through a single TCP/TLS connection. Small bursts of audio and video data were tagged with identifiers indicating which logical channel they belonged to. At the receiving end, the streams were separated again and delivered to their corresponding audio and video components.
I think a similar approach could potentially work today over Tor. Tor can provide surprisingly good throughput under the right circumstances. The bigger problem for real-time communication is latency and, particularly, variation in latency. But for many kinds of live streaming, being truly instantaneous isn't necessarily required. We could deliberately introduce a delay.
Imagine that the local DarkSpeak instance sends audio and video frames through a multiplexer and then transmits that multiplexed stream over Tor. At the receiving end, the application separates the individual streams again. Instead of immediately playing each frame as it arrives, however, the client maintains a buffer. For example, the stream might initially run five seconds behind real time. As long as the Tor connection can reliably deliver everything required during that five-second window, the receiver can provide continuous playback even when individual packets or frames arrive with varying delays. If five seconds isn't sufficient, the buffer could increase to ten seconds or more. Ideally, this would be adjusted automatically. The client could continuously measure connection stability, throughput, and how frequently data arrives too late for the current playback position. It could then increase or decrease the buffering delay accordingly.
This becomes especially interesting for group video conferencing. Different participants may have very different network characteristics, so their streams could arrive with different delays. The receiving client would need to synchronize them by applying a common playback delay. Everyone would then appear synchronized on screen, even though the conversation being displayed actually happened several seconds earlier.
There are obviously technical challenges here, and the practical limits would have to be discovered experimentally. But I think it is worth trying. If it works, DarkSpeak could potentially provide an alternative approach to conventional WebRTC communication: audio, video, and small-group live streaming routed through Tor, without depending on the conventional NAT-traversal and relay infrastructure normally associated with Internet calling. It wouldn't necessarily provide the near-instantaneous experience people expect from an ordinary video call. Instead, the trade-off would be deliberate latency in exchange for privacy and the ability to communicate through Tor.
Whether this works well enough in practice remains to be seen. But that's exactly why I want to build it and find out. Live streaming over Tor would be an extremely interesting capability to have in an application like DarkSpeak.