Author Topic: Feature Requests  (Read 17419 times)

0 Members and 1 Guest are viewing this topic.


  • Guest
Re: Feature Requests
« Reply #15 on: March 06, 2005, 10:27:32 AM »
I would like to see

end to end encryption in mute,

as nate has already given green light for that request in one of the next versions.

thanks for Napshare 2.1, as well Mute MFC 006 should have it.

Offline bitz

  • Advanced
  • ***
  • Posts: 160
  • Karma: +2/-0
  • Planet Peer Community
    • View Profile
    • My Blog
Re: Feature Requests
« Reply #16 on: March 06, 2005, 08:49:06 PM »
Requests/ideas for version 006.

How about magnet link features?

All things said before:

1. multisource download.

2. resume unfinished downloads.

3. ability to limit upload and download

4. end to end encryption

Having magnet links would be very nice.

Then add a html viewer (no I'm not requesting a regular webrowser) that supposts viewing .war files (zipped up websites), so that archived websites can be shared/hosted on mute's network (which would make having external content link sites pointless).

Anti-networking-ident features - Basically features that make identifying mute clients by thier networking hard/impossible. To further limit the peers exposure to systems outside the mute network. I don't know offhand if mute already has such features or not (it very well could, it's been awhile since I've read up on it and the latest version could for all I know).

So new list of requested features

1. magnet links
2. html .war viewer
3. Advanced Boostrapping (see below, also eliminates need for webcaches)
4. multisource download.
5. resume unfinished downloads.
6. ability to limit upload and download
7. end to end encryption

Advanced boostrapping
Some ideas for advanced bootstrapping
protected bootstraps
proxied messege based bootstrap communications
Limited use of bootstraps
Encrypted handshake/bootstrap messeges

Protected boostrapping - basically there would be a listing of say 1000 dyndns hostnames, maybe one or two real bootstraps would be listed. When bootstrapping into the the network clients would simply broadcast a bootstrapping request to those 1000 hosts, then the boostraps would send back entries for the clients local peer cache (basically x local peers and x remote peers + x fake peers). The bootstraps would only allow proxied requests, any direct communications would be forbidden/rejected. Thus the bootstraps would have some denyability and very limited exposure.

Localization - when sending bootstrapping requests, localization data would be sent, so that the local peers returned would be within same country/state/city (depending on the number of clients within each area), so remote peers would be peers from other countries/states/cities.

Proxied messege based bootstrap communications - Broadcasted boostrapping requests/responses would pass through a proxy, which is what we use tor for. So no direct connection and communication would exist between the requesting clients and bootstrap clients. In fact it'd be very hard to confirm that a particular system is acting as a bootstrap or not. Only the requesting client's dyndns hostname would be exposed to the bootstrap.

Limited Use of Bootstraps - This could be achieved via a local cache of peers (though the local cache could be just the peers dyndns hostnames and there even could be lots of fake entries). Tor would be used for initial handshaking between clients when they attempt to reconnect to the network.

Encrypted handshake/bootstrap messeges - Not only would the handshake/bootstrap communications be proxied, they would be encrypted. Meaning that only mute clients could tell they are handshake/bootrap communications. So requests sent to fake hosts and passing through the proxies wouldn't be recognizable as mute handshake/bootstrap messeges.

These are just some ideas/requests. They may need more work and thought put into them, so I don't really expect to see them implemented, I just think they would nicely improve things.

Yeah I know, having lots of fake entries and using proxies in this way wouldn't be such a swift idea for many things, however IMHO that for bootstrapping it's great and isn't really abusive.

Once a mute client connects to another mute client, the mute eula would apply, so certain abuse clauses could be applied to anyone/system connecting to the mute network/other peers. Specifically when it comes to liability and such, possibly even concerning the sharing and distribution of mute peer addresses. Basically it would state that by connecting and using the mute network you're basically joining a online group/club and agreeing to it's rules, that under it's rules you can only share and distribute peer addresses and information to other mute peers, sharing and distribution outside of the network is strictly prohibited and a violation of the eula. Warn that each peer is responsive for the content on his/her own system.

Really I do not know the exact effect such a eula would have and just how effective/binding it could be. It's just another idea anyways.

"The first rule of fightclub is..." well you get the idea. Though really considering anyone that is running mute (or a mute compatible client, if any exist) can join the network, it isn't really a closed network.

Offline tobiash

  • Regular
  • **
  • Posts: 72
  • Karma: +0/-1
  • If I can have it, you can have it too
    • View Profile
    • MyMute
Re: Feature Requests
« Reply #17 on: May 30, 2005, 08:30:10 PM »
I got the idea that it could be cool with a user-counter that shows how many active users there are. It could get it's data from the webcaches by counting the unique ip's on all the webcaches we known about. I would code it myself, if it was not for the fact that I code like a rock swims.

Best Regards
Truth is in the eye of the observer!


  • Guest
Re: Feature Requests
« Reply #18 on: August 08, 2005, 01:45:18 AM »
A remote, web-based GUI would be nice, so I could run MUTE 24/7 at home, then connect from work via web browser and search/download.  Either a built-in microserver or something PHP/SQL based (the program writes results to the database, which the web app reads from).

Offline camper

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
  • Planet Peer Community
    • View Profile
Re: Feature Requests
« Reply #19 on: September 22, 2005, 06:48:44 AM »
What I miss in the download is the ability to pause/stop/resume a download. As search is rather irregular, one time you get it next time it is gone, I would like to put it in download when found and download when I want to.
Hope it is possible!
I use mute mfc for a month and I like it, it deserves more users.

Offline lordfoul

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
  • Planet Peer Community
    • View Profile
Re: Feature Requests
« Reply #20 on: March 09, 2006, 10:34:43 PM »
I am encouraged with the continued development of the client and happy with it's progression to date. Mute is by far the most usable anonymous client our there.
These are the features I see as important to the success and usability of the client in the future.

1.Multiple Shared Folders is a must
2.Pause and Resume
3.Hashlink Import Export
4.Bandwidth Control would be nice (I use netlimiter to accomplish this)
5.Total users stats would be nice and total files available, as well as estimated download speeds in K/Bs or Mbs even (People like stats)
6.Anon chat would be the bomb

Well my 2 cents.

Yay for v 0.5  Multi-source and vuln. fix booyah!
« Last Edit: March 09, 2006, 11:02:26 PM by lordfoul »

Offline DestinyBlind

  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: Feature Requests
« Reply #21 on: June 16, 2006, 05:08:03 PM »
Someone before said magnet links are important.
I second that. Also, if the file hashes are SHA1, why not use the urn:sha1: format to display them? Even takes less space because it does not use Base 16 but something higher.

And, what about the possibility to specify some host:port pairs that my MUTE will always try to connect to that don't count against the normal connected hosts? That way i can always keep connected to my friends.

Offline tym100

  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: Feature Requests
« Reply #22 on: July 21, 2006, 10:09:44 AM »
A proxy setting,

I think that this page can help to develop this option :