Additions:
- [[BulkRealtimeFlag Bulk vs realtime flag]] for requests. Bulk requests will be optimised for throughput, realtime requests optimised for latency. Fproxy would generally use realtime requests, big downloads would generally use bulk requests. This should be a major improvement on the current strategy of turtling slow requests to boost throughput and latency, although we might keep that to some degree.
Deletions:
Revision [3269]
Edited on 2009-08-07 10:36:25 by Digger3 [created link for bulk/realtime flag to hold page with details]Additions:
- [[Bulk vs realtime flag]] for requests. Bulk requests will be optimised for throughput, realtime requests optimised for latency. Fproxy would generally use realtime requests, big downloads would generally use bulk requests. This should be a major improvement on the current strategy of turtling slow requests to boost throughput and latency, although we might keep that to some degree.
Deletions:
Additions:
- Plugin updating over Freenet.
Additions:
- Pause mode, and a system tray icon to trigger it.
Additions:
- More work on usability - tidying up the web interface, a wizard for inserting both files and freesites, etc.
Additions:
- Multi-container freesites. Saces has this working in git, but it is not enabled yet, mostly because there needs to be significant work to make it work well with persistent requests.
Additions:
- More peers for faster opennet nodes, and maybe fewer for slower nodes. This is trivial but will likely require some research and tuning.
- Bulk vs realtime flag for requests. Bulk requests will be optimised for throughput, realtime requests optimised for latency. Fproxy would generally use realtime requests, big downloads would generally use bulk requests. This should be a major improvement on the current strategy of turtling slow requests to boost throughput and latency, although we might keep that to some degree.
- Bulk vs realtime flag for requests. Bulk requests will be optimised for throughput, realtime requests optimised for latency. Fproxy would generally use realtime requests, big downloads would generally use bulk requests. This should be a major improvement on the current strategy of turtling slow requests to boost throughput and latency, although we might keep that to some degree.
Additions:
Freenet 0.8 is the version after Freenet [[FreenetZeroPointSevenFive 0.7.5]]. Likely features:
- Freetalk. Similar to FMS, involving a Web of Trust plugin, which is a general purpose collaborative filtering system which can be used by other applications as well, and the Freetalk plugin, which is a chat forums system with both web and NNTP interfaces. You can try Freetalk now but it won't be ready for 0.7.5.
- Multi-Hash Keys: Redundancy in the top block. Splitfiles (any file that doesn't fit in 32KB compressed) have 100% redundancy - we insert N data blocks, and then another N check blocks, and within a segment (128 blocks), we can reconstruct all the blocks from any 128. But above all this there is usually a single CHK block. While this is probably more popular than the lower blocks, there is still a very real possibility of it getting stuck in a black hole, or being hard to fetch after a while: we initially push data to 24 nodes' caches, but it will only persist in the store on 3 nodes, and they might be offline.
- Bloom filter sharing, and related security improvements. Let our peers know what is in our datastore, essentially. This should result in a major improvement in performance for both popular and unpopular files, in both data persistence and speed.
- Freetalk. Similar to FMS, involving a Web of Trust plugin, which is a general purpose collaborative filtering system which can be used by other applications as well, and the Freetalk plugin, which is a chat forums system with both web and NNTP interfaces. You can try Freetalk now but it won't be ready for 0.7.5.
- Multi-Hash Keys: Redundancy in the top block. Splitfiles (any file that doesn't fit in 32KB compressed) have 100% redundancy - we insert N data blocks, and then another N check blocks, and within a segment (128 blocks), we can reconstruct all the blocks from any 128. But above all this there is usually a single CHK block. While this is probably more popular than the lower blocks, there is still a very real possibility of it getting stuck in a black hole, or being hard to fetch after a while: we initially push data to 24 nodes' caches, but it will only persist in the store on 3 nodes, and they might be offline.
- Bloom filter sharing, and related security improvements. Let our peers know what is in our datastore, essentially. This should result in a major improvement in performance for both popular and unpopular files, in both data persistence and speed.
Deletions:
- PremixRouting is an essential security feature, similar to onion routing, which is a key requirement for 1.0.
- PassiveRequests would be very helpful to messaging clients, for example enabling outbox polling (the basis of much better anti-spam measures), and would be a major step towards high latency operation
- PublishSubscribeStreams might enable live streaming (albeit with some latency), and other interesting applications
- OneToOneStreams would enable centralised servers hidden by freenet like tor hidden sites (they would be slow, and somewhat vulnerable, so a last resort, but useful for many applications)
- SwappingImprovements: it may be possible to significantly improve the performance of the swapping algorithm. This will be essential for large networks. Also a good deal of work needs to be done on improving the security of the swapping algorithm.
Future features:
- [[TransportPlugins Transport plugins]] and [[HardStego better stego]]
- [[FreenetToOperatingSystem Freenet integration to operating systems]]
Additions:
- SwappingImprovements: it may be possible to significantly improve the performance of the swapping algorithm. This will be essential for large networks. Also a good deal of work needs to be done on improving the security of the swapping algorithm.
Deletions:
Additions:
- SwappingImprovements: it may be possible to significantly improve the performance of the swapping algorithm. This will be essential for large networks.
Additions:
- OneToOneStreams would enable centralised servers hidden by freenet like tor hidden sites (they would be slow, and somewhat vulnerable, so a last resort, but useful for many applications)
Deletions:
Additions:
- PremixRouting is an essential security feature, similar to onion routing, which is a key requirement for 1.0.
- PassiveRequests would be very helpful to messaging clients, for example enabling outbox polling (the basis of much better anti-spam measures), and would be a major step towards high latency operation
- PublishSubscribeStreams might enable live streaming (albeit with some latency), and other interesting applications
- OneToOneStreams would enable centralised servers hosted on freenet like tor hidden sites (they would be slow, and somewhat vulnerable, so a last resort, but useful for many applications)
- PassiveRequests would be very helpful to messaging clients, for example enabling outbox polling (the basis of much better anti-spam measures), and would be a major step towards high latency operation
- PublishSubscribeStreams might enable live streaming (albeit with some latency), and other interesting applications
- OneToOneStreams would enable centralised servers hosted on freenet like tor hidden sites (they would be slow, and somewhat vulnerable, so a last resort, but useful for many applications)
Deletions:
- PremixRouting
- OneToOneStreams
- PublishSubscribeStreams
Of the above, premix routing is a key requirement for 1.0 because it fixes several major security issues.
The rest are client-visible features, enabling audio (and possibly video) broadcast over Freenet, eliminating the need for clients to poll a series of KSKs for messages, and allowing (slow) interactive servers over Freenet.
Additions:
- [[FreenetToOperatingSystem Freenet integration to operating systems]]
Revision [1771]
Edited on 2007-02-07 17:12:29 by MatthewToselandAdditions:
Future features:
- [[TransportPlugins Transport plugins]] and [[HardStego better stego]]
- [[TransportPlugins Transport plugins]] and [[HardStego better stego]]
Revision [1737]
Edited on 2007-02-07 16:08:29 by MatthewToselandAdditions:
Of the above, premix routing is a key requirement for 1.0 because it fixes several major security issues.
The rest are client-visible features, enabling audio (and possibly video) broadcast over Freenet, eliminating the need for clients to poll a series of KSKs for messages, and allowing (slow) interactive servers over Freenet.
The rest are client-visible features, enabling audio (and possibly video) broadcast over Freenet, eliminating the need for clients to poll a series of KSKs for messages, and allowing (slow) interactive servers over Freenet.
