the power of broadcast
[a revolution in mass-scale content distribution]
Showing revision 30
ignore .DS_Store files in the received and broadcast file browsers. It's small but very annoying on Mac OS X
checkboxes to select mutliple files for broadcast without selecting an entire folder. There are some checkbox issues.
how to add file browse jump support to a skin.
subscription info links in the catcher.
between file pause for broadcasts.
Chunk-based file broadcasting (instead of whole-file broadcasting) to accomodate for bandwith differences with better speed (like with bittorrent). More about this idea in this slashdot thread: http://slashdot.org/comments.pl?sid=65009&cid=6008476
Why not BitTorrent Discuss Bittorrent vs k2b
a centralized list of the channels (Perhaps a channel distributing channels?)
the ability to grab certain broadcasts without having to subscribe to a channel (especially useful for high volume channels)
ability to ignore channels in catcher
store the caught receiver keys differently. my caught_receiver_keys directory is 600kb in size, but takes up 13megs, due to a 4k cluster used for each 184 byte file.
Codify trust levels:
Codify trust levels. There is significant description of trust within the konspire2b documentation, but very little of it has to do with a system that users can do something about outside their own head. This might be accomplished with computer-aided memory of which keys distributed good content in the past, and which didn't. This leads on to distributed recommendations: If someone that I've marked as "Wow this person sends some damn awesome stuff" sends me a recommendation for a channel I've already subscribed to, perhaps it'd be neat to put this in a separate "ratings" meter next to the subscribed channels and the prebroadcasts? This leads in to:
Negative recommendations. If I'm a popular broadcaster with thousands of subscribers and I happen to get burned by some dumbass who said he was going to broadcast scanned works of art but instead broadcasts old Stileproject videos, I would like to be able to let my subscribers know that I've been burned by that key. Depending on their level of trust, then my negative recommendation can influence ratings that show up next to the prebroadcasts of that particular key. So two meters: Personal ratings for a key; and trusted recommendations for a key. This leads to:
More than just yes/no recommendations. If someone sends me 10 movies that I love, I could mark him with 10 points. If someone else sends me 9 movies I love and one I hate, then he gets 9/10 or 90% rating. In a recommendation, how about the ability to send this rating out along with the recommendation? Interesting things can be done with weights then also.
To ease this in, how about a little button sitting next to the ratings on subscribed channels "send recommendation" to make it easy?
+ Once recommendations reminds me a lot of the system of Media Folders proposed (and implemented?) by the OpenCola Folders project - http://sourceforge.net/projects/opencola/ - although their proposed distribution system was based on Swarmcast (same people). I note that OpenCola.com has morphed into a knowledge management company (but clearly based on the same technology).
Make the file browser smarter:
It's not smart enough to change between drives on Windows machines without typing it in manually in the URL.
Daemon for *Nix:
Make the whole thing into a system service, ideally one available only in the "k2b" (or "kast", or what have you) group, that pulls preferences from the appropriate home directories. Should be possible for specific implimentations to pool all files into a single kast download area or individual user's, or in any other arrangement that can typically accomplished on a *nix.
Skin Root Tag
A Skin Root dir tag, or documentation w/ regard to /skinimage?file=".." sufficient to incorporate embedded objects or css in new subdirs of the skin dir.
In the case of a lan with many people on it (about 500) which is connected to the internet but has a traffic limit, it would be nice to: - have a central proxy that accepts broadcasts from the internet and uploads to other nodes in the internet and forwards the files locally - be able to limit the 'inner' nodes to only communicate with the proxy node. this change should be quite easy. Without special features on the proxy an admin would have to add channels to the proxy before they are avaible in the lan, but this can be done out of band.