Editing revision 34 of suggested modifications

main page | recent changes | preferences

Editing old revision 34. Saving this page will replace the latest revision with this text.

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.

Even on unix machines, it would be great for the file-browser to remember its last directory -- this would make publishing a lot quicker

=== 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.

=== Kast Proxy ===

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.

=== Chat ===

Some way for subscribers (or anyone, I suppose) to communicate with the channel op while maintaining some level of anonymity would be nice and would help with informing the op what sort of content people are interested in. I suppose one could set up a channel and give out the private key publicly as a sort of messaging service, but this would not be well integrated with the rest of kast.

The fact that everyone'd need to be online to get the messages is a bit of an issue, but maybe bundling up the messages into a larger packet and resending that frequently (since text is small) might be a good idea.

Making this optional for a channel would probably be a good idea, since sometimes an op wants to push content down your throat, but if there was, say, a music channel and people wanted a certain song, why not post it for that person and any others that are online?

Perhaps some method of slashdot-like commenting on a story would be useful.  By definition, the listeners on a channel can get each others' files, so some way of "this is a reply to x for all subscribers of x" would be useful.

=== Multiple Channel Owners ===

With this idea, you could have multiple with "write access" to the channel. This would allow for more constantly updated channels, as well as a nifty bonus for corporations and groups. This could act as a content distrobution method from managment to employees, with both managers and supervisors being able to integrate new content. Also, this would be useful in workgroups and such, similar to an idea microsoft came up with recently, where everyone shares there favorite files. It's like a club... or something.

=== Remote Access ===

As sume of us are on the road alot, having a server at home collecting files would be nice. With Kast's web interface it wouldn't be difficult to add either a login/passqword interface to the front, or firewalling softs to guarantee the validity of the remote user.

summary:
this change is a minor edit.
(visit preferences to set your user name.)

view other revisions
main page | recent changes | preferences