Pit Schultz

1. towards an open live event schedule interchange standard

today: lots of live events are not getting recognised by the "end users" because they simply do not know it is happening. the central web event portals are numerous and do not cover small and interesting events. meanwhile a small live stream provider often doesn't have the means to do enough (web)promotion. Search engines are usually to slow to cover live events. and there are no mailing lists which proved to be very effective tools to motivate people to start certain streams at a specific time, besides the bigger web event portals, various efforts were made to build "independent" schedulers, which mostly turned out to be compatible to no more than themselves. in this way the portalisation of commercial world was just mirrored and no one was really helped. Until upcoming versions of streaming media players provide an internal live event scheduler which is usable for small streaming stations as well as the gatekeepers of big media there is still the need for an "own" but open solution, similar to a tv guide.

tomorrow: the data format of an open exchange format of a live event could go like this: channel name - location - title - line-up - related URL - start date + time - duration - streaming standard - genre - timezone - commentary. to exchange the data, a mailing list is used, a project has to be subscribed to post to it. after you are subscribed you can only write through an interface. (which calculates an id code) this way messages remain machine readable and also human readable. one message could contain more then one event. a set of scripts will do the following: - enable to post (format) your own messages - filter the message base according to keywords, genres, times, and generate tables which are usable in own web pages - the basis would be PHP/mySQL. Anyone who likes could start their own local database. Someone else might program a submit engine which enters the data into bigger event schedulers. Everyone will be allowed to use the live event scheduler or contribute to it as long as the streaming event is really happening. If the load gets to high, genre specific lists, or moderated lists might be useful. known issues: copyright, rights management, recordability, reliability, price.

2. remote home recording
a lawyer is needed to check the following.

Instead of offering the audio/video archive of a live event publicly (on demand) and risks running into 'legal' problems it is done the following way: the user subscribes and opens up an own account with a virtual file space. before she accepts an agreement. then she will be able to click on live-events throughout the next month or so and select those she likes to record for private use only. a deep link blocker makes sure that there is only the possibility to stream the file on demand but not download it. only the read permissions have to be set, so every recording needs just one copy. under certain circumstances the user might share the access to a file which remains private. such a service could run for many different stations, then it should be based as a non-profit company or 'genossenschaft' which offers backend infrastructure to a number of shareholders without an own 'central portal'. such a service should not be patented, but used by small independent streaming stations.

3. shared resources

**legal database
a number of licenses specialised on streaming media, live events, open content, digital distribution, net marketing is set up by a group of legal experts. by joining the network one has access to these resources.
** bandwidth
a network of servers provides optimal bandwidth in a specific area, multicasting is used as soon as possible. preferably open standards and GPL software are implemented.

** content
users can share, trade or publicly offer certain content to other members (but not to non-members?). in this way some groups can focus on text based content or special features, while other focus solely on music or live events. also, some kind of non-linear programming and
24/7 automation is possible without giving up the 'character' of a streaming station.

4. feudalism?

Any representative or central administration of a "streaming media guilt" or genossenschaft of a free net radio network should be elected yearly by its members. The user of such a system should have maximum possibilities of participation, technical tools like jukeboxes and chat environments are just the start of development. broadband quality service might be offered for a subscription fee in the long run to be able to afford the traffic costs, a normal quality stream should be always offered for free. Revenues are shared as possible.

5. the champagne model

by joining a genossenschaft any member has to pay its fee due to a "flat-rate" within certain maximums and minima. this would work similarly to shared use of machinery in the agricultural sector. the product will be partly marketed by the genossenschaft but can also be marketed by the member itself. state subsidies are used for further investments in the infrastructure. any profit above the maintenance of the shared resources would go to the specific member according to the content they delivered. certain tools will offer to provide the required statistics. in-stream advertisement has to not exceed a maximum one agreed on. such and other guidelines are agreed on in member meetings, online or offline and administrated by a main board which has to be legitimised by the majority of the members every year. The cost of software development has to be put into the equation, too. every member has to brand its content with the "stamp" of the guilt. the declared focus is high quality content projects and exclusive contracts with sources and producers of original content. Only in this way the 'champagne model' would work within a bigger market.

6. inclusion/exclusion

new members get invited by old ones, which introduce them and be responsible for them in the introductory phase. the exclusion of a member can only happen after a decision of the administration plus a majority vote of all members. the number of the core group shouldn't be bigger then about 5 projects.

7. educate

a certain percentage of the content program and resources should be used for 'educational use' like a daily news editorial or special features which are not profitable in any way, but agreed on to be important. those and other guidelines may be a product of meetings.

klubradio, berlin, september 2000

Note: This text was published on the list of net.congestion and was also included in the festival catalogue.