>Briefly: >On a working routing fabric, such as that which should be provided by 0.7 >with oskar's new algorithm, we can build various services: >- Insert and retrieve data (0.5 semantics) >- Notify when a piece of data is inserted (passive requests) >- Messaging from one node to another across the network via location > (e.g. to tell them your new IP address; not very reliable as locations > can change) >- Inserting data pointers (maybe; inverse passive requests) >- Publish/subscribe. >This is a 1:many, very close to real time, reasonably reliable, means of >sending a stream of data around anonymously. A user can create a stream, >and then post messages to it. Another user can subscribe to that stream, >over the network, using the stream key, which will be >PSK@<blah...>/<name> . >>=20
>> If another node wants to participate, it is enrolled into the tree. If a = >message comes in, it is routed up to the root node, then all the way throug= >h the tree to reach all stream participants. >> * What are the security and anonymity aspects when subscribers span up a = >tree? Isn't that somewhat trace- or probeable? > >How so? dunno, but as i/r (0.5 insert and retrieve) and p/s are in effect entierely different services using oscar-routing ;) on the network fabric I could imagine that there are * different security aspects on both (i/r: correlation if a splitfile breaks up into many requests, p/s: (real)time timing attacks, traces through the tree, detectable subscription mechanics?) * combined aspects as both (all) services use the network fabric and its routing for different purposes. so I'd assume that every single service has to be reviewed for anonymity/security issues * would a plug-in architecture for services work? then again... that's of not much use as a plugin had to be widespread to work at all as not understood messages ought to be dropped. * would it be possible to deactivate a specific service? issues? >> * There was a streaming test implementation in the old 0.4 aera made by f= >ish featuring FECed chunks of data that were adressed like edition freesite= >s (there was some additional meta IIRC). So you could skip within that stre= >am, old unwanted parts of the stream would fall=20 errata: it was a DBR :) >Indeed. Which never really worked across the network, was absurdly >inefficient, and at best could have achieved latencies of minutes. I >think we estimated that 90 seconds might be achievable at one point. >Failure tables meant that half an hour was a realistic minimum at the >time, but are no longer a problem. but it would be good for non-realtime audio- or videofeeds as it's mainly designed for bulk-transfer? also it would be FECced, meaning the stream won't fade too fast and could be (re)viewed at any time as the stream-data persists >> * Are the datachunks cached and routed in the same way as normal freenet = >CHK data? > >They are not cached in the same way, but the whole thing depends on >routing. > >The function of the tree is to fan out the messages, so we don't have >individual connections to each client from the root node. On each node >in the tree, the data is cached, and a normal subscribe request will >terminate when it reaches it. _are_ there any data chunks for p/s or is everything stored within the controlling messages? how far a stream could be accessed into the past? >> * Are those streams to be understood as "shoutcast" audio streams? as new= >sfeeds? as read-only filestreams? IRC-style streams? What are their main us= >e and what are they geared for? bulk transfer? low latency? > >Anything from a non-polling RSS to IRC. Low latency. NOT bulk transfer, so it's not "read only" but a stream can be written into. from any participant? then it would be like... a frost board, right? I assume any posted message would hit the tree, wander to the root and trough the full tree again. Now imagine this for many posts to that board. Wouldn't the tree stick out at network analysis? >> * What if DNFs are common? or at least often enough to have the tree brea= >k into pieces having to Resubscribe over and over? > >Then routing doesn't work, and ordinary requests won't work either. This >depends on working routing. However everything suggests that oskar's new >routing algorithm CAN work. DNFs can happen even if routing works; either by broken connections (provider auto-disconnect), shut down nodes (u wanna play qu4k3!), temporary network throughput decrease (grabbing the new OpenOffice/Knoppix.iso/...), routing flaps, etc. And even a _single_ DNF would make the tree "panic" and wiggle around. I hope the effects won't be too drastic if that happens >> Workflow: >> You seem to be using at least some of your valuable (you being the only o= >ne that is able to bring us 0.7) time on p/s. > >Volunteers are always appreciated. :) :) but even volunteers have to be qualified and have to know where the trip is going to be able to help >> * What priority is it? Maybe this could be considered 0.7.2 stuff and get= > 0.7.0 running first? > >I am of the view that something new and fun is important to the goal of >getting some money and enthusiasm so we can continue to work on the rest >of 0.7. IRC over Freenet is something we've never been able to do. And >furthermore, IRC is a great way to establish a community, as shown by >IIP and I2P. Certainly there is loads to do on 0.7; it just seems best >to work on this first. We have basic insert/request working, we need >splitfiles, and SSKs, and FCPv2, and fproxy, and rate limiting, and so >on. so i/r is somewhat working but unusable for a end-user. wouldn't it make sense to have at least something for the masses to play before having tens of half-complete things which no user can enjoy? 0,02?
