Allow station edits somehow again.

[Wikinaut]

Some stations need edits, for example, the icons and title of "Kulturradio". How can I update that? http://www.radio-browser.info/gui/#!/history/960c1c0e-0601-11e8-ae97-52543be04c81

• Should become "RBB Kulturradio"
• Icon is not shown in the app

[segler-alex]

for now there is no possibility, i am switching to work on radiodroid again now, not on the backend. backend is in a usable state currently. i implemented all old features and added even some new. this was a lot of work. we have to many bugs in radiodroid now, which have to be fixed.

more than 100 Bugs in radiodroid

[Wikinaut]

How to fix errors then?

[segler-alex]

no way at the moment. sorry. to get at this problem, we have to find solutions for multiple subproblems first.

1. bad people are out there, they want to destroy the database, they tried multiple times. still to this day. i don't know their intentions, but my thoughts on this are, that there are other lists out there which want to make money... so. even now sometimes there are stations added, which tried to discredit this project. at the time i deactivated editing we were at the point that we were losing this war. a lot of people tried to fix stations, every single day. but breaking stuff is much easier than keeping it working. so i had to stop it. i also have mixed feelings about this, but in my opinion it was better to give edit up, than to keep a lot of people occupied fixing stuff every day. we need a bullet proof strategy before i open edit again.
2. people are to this day writing me mail if i could change single entries, but for me this has 2 problems: a) liability, if i do change entries myself, i think i get liable for it, then people expect me to do it always and if at some point bad things happen, i could be sued for not doing it. so i never do it, so people don't expect it. i am no jurist, but i read something along these lines. b) time, if i start changing entries myself, and do this always, this would take a lot of my time. which i can't use for programming. also i started this, because i wanted to do something different, than other lists. there are other lists out there which are curated. but radio-browser is more than that, i want to find new technical or organisational solutions for these problems. a system that can lift its own weight, and does not have to be carried. that is why i already added a feature in the backend which should in the future allow the stations themselves change their own entries, by adding more metainformation to the stream. i have not yet documented it, i first want to make the next radiodroid release. then this is the next thing. as i said, a lot of work...

this got longer than i thought, but i hope i could make it more clear, why i do things the way i do.

[Wikinaut]

I understand, but look, should I then always add a new entry when only a few things need to be changed like in the example?

[Wikinaut]

You could build up a crew of a few reliable people you trust which can change items.

[segler-alex]

this i forgot to write:

1. people also suggested some kind of login system, where a few trusted people fix things. but this just moves the problem. the bad people out there also would add logins, and change stuff. you could argue, to just allow some people accounts to edit stuff. but then it would go in a bad direction in my opinion. i don't want to go this direction, because it would be the wikipedia way of doing stuff. and they have their own problems, especially with getting new people on the train.

[Wikinaut]

Hi, just again: how to fix small errors with existing stations? If a new entry is added, the old still remains.

[Wikinaut]

Or: can I chose to use my own list ?

[segler-alex]

for now there is no way, as i said. sorry there may be a way in the future, we have to discuss this more, as i already explained. i am focusing my time now on https://github.com/segler-alex/RadioDroid/milestone/1

[zo-shin]

I don't fully agree. 1 - Disabling edit doesn’t solve anything. If the destroyer wants to ruin the database, they can make it simply by adding as many entries containing valid play links and trash names as possible, which has the same result of editing existing items. 2 - No one has been interested in ruining the database so far. As mentioned in article 1, if anyone wanted to do it, it should have happened.

[Porkepix]

2. people are to this day writing me mail if i could change single entries, but for me this has 2 problems:
   a) liability, if i do change entries myself, i think i get liable for it, then people expect me to do it always and if at some point bad things happen, i could be sued for not doing it. so i never do it, so people don't expect it. i am no jurist, but i read something along these lines.

I'm not a lawyer myself, but from the understanding I have of such situations, it's actually a little bit different. On the Internet there're usually (at least in France with what we call the LCEN law, which I expect to be similar in other European countries as it's a transposition of a European directive, 2000/31/CE) two statuses, either you're a publisher, either you're a host.

• The first one is fully responsible for everything that's published, and apply controls before publication, systematically. That's for example the case of a newspaper. This one can be held responsible for whatever is published.
• The second one never control before publication (or he would become an editor, which he wouldn't wish), but have to answer any legal complaints that could happen. Think social medias and so on. No responsibility can be held in this case as long as legal complaints are tackled in a timely limit.

Now, I'm not sure exactly about how it apply here as the object of the content is more about the radio streams themselves, but the DB still contains quite some additional information.

So yeah, there could be trouble if, in the second situation, you don't answer complaints if there are some (what's difficult here is, I guess, that this doesn't apply to the whole edit requests).

[Anachron]

How about allowing edits and new entries but they must be approved from a core team? Then if you have X% approvals with at least Y changes/addition in Z of time you get added to the list of trusted members.

Additiomally use API keys and log changes/additions with before and after values.

[segler-alex]

there were again new stations with in germany forbidden imagery. i had to delete the stations manually from all 3 servers. people still add illegal stuff.

[kekukui]

The creator of a good, working/approved database entry should be allowed to maintain it (or at least update the stream URL when the link breaks.)

[olaf4]

Suggestions to prevent someone deleting or destroying the database:

• enable editing of an entry, but only of an entry that is known to be broken = the known stream url does not work anymore
• enable editing of only one url a day

This way nobody would be able to destroy a working entry of the database.

[Porkepix]

Suggestions to prevent someone deleting or destroying the database:

* enable editing of an entry, **but only of an entry that is known to be broken** = the known stream url does not work anymore

* enable editing of only one url a day

This way nobody would be able to destroy a working entry of the database.

Thing is, it only covers part of the needs, because for example a radio station could have disappear, metadatas could be incorrect, or outdated or, case I see the most, there are duplicate entries that should be merged, each of them with distinct information, eg. one have a picture and the other doesn't etc.

[olaf4]

Perhaps some kinds of registered users can be allowed to edit the entries, for instance the same people that have reported corrupt data in the data base here at github. Is there a way to declare the content of data base itself to be a github project?

[Porkepix]

Is there a way to declare the content of data base itself to be a github project?

If it was in text files, yes, but here it seems to be in a MySQL database, so no. It would need some Web frontend for it (which may already exist), with permissions management and so on.

[olaf4]

incremental data sets That goes back to an idea, Felix von Leitner has published. He suggested to build data structures in an incremental way, so that the data in the data base can only grow, but never can be deleted. That will prevent most kinds of vandalism, because deletion does not exist. People can only append new data to the existing.

Regarding the radio browser data base that would mean:

• people can only add a new icon-url additional to the already existing
• people can only add a new streaming url additional do the already existing
• people can only add an aditional home page url
• and so forth

On the side of the clients or the data base the algorithm that delivers the data has to be changed in a way that it is only accessing the last entry of each field, ie. the last url, last stream url, last icon url.

That way all of the existing entries would be contained in the data base. And an administrator can undo vandalism by simply returning to the last valid state of the record.

[kekukui]

@olaf4 - Perhaps some kinds of registered users can be allowed to edit the entries... @segler-alex - we need a bullet proof strategy before i open edit again...

I have devised a set of parameters & specifications for a moderation system, and submit this proposal for review & comment.

---

1. A user registration system will permit the creator of a new database entry to maintain it. All new database records will be sent to the moderator's queue for approval. A registered user can also flag invalid database records for moderator review.

2. Registration will require a CAPTCHA to prevent a malicious user from creating many accounts.

3. A database record will contain a separate field for station name and government-issued call sign (if applicable)

4. If the stream URL in a new database record matches the stream URL in an existing database record, the new database entry will not be accepted, but a registered user can send a message to the creator if they need to suggest changes in spelling / tags / et cetera.

5. If a database record is updated with a working stream URL, the database will retain a history of the previous stream URL.

6. Registered members can flag a database record as invalid when:

• the call sign, logo, or title does not match the stream content
• the stream does not work

7. When a station is flagged as invalid because the stream link is broken, the server will verify this. If the stream works, the complaint is ignored.

a) If the stream is verified broken and the previous stream URL in history works, the previous version becomes the current version and the creator is notified.

b) If the stream is broken and the previous stream URL does not exist or does not work, the record is disabled and the creator is notified. The station will not appear in search, but can be edited by the creator. When a working stream URL is provided by the creator, the record is enabled. But if the new stream URL matches the URL in an existing active database record, the suspended record remains inactive. All inactive records will be destroyed in 6 months. The creator of an inactive record can also destroy it.

8. User accounts which create a valid new database entry will be invited to join the moderators group. Moderators can choose to be alerted by email or push notification when their assistance is needed. If a moderator does not take any action (resolve or decline) on 4 sequential tasks, they are removed from the moderator's group, but can re-join by checking a box in the user profile, and will be invited to join again if they create a valid new database entry.

9. When a working stream is marked as invalid because the title or logo does not match the stream, a notification is sent to the creator and to the moderator's queue. Either one can then correct the error.

10. If the number of complaints for any station during a period of 1 hour exceeds 5 percent of the total play count from registered users in the same hour, the station will be automatically suspended and sent to the moderator's queue.

11. User complaints about invalid database records will be assigned to moderators on a random basis. If a moderator does not resolve an issue in 4 hours, it will be randomly assigned to another moderator, unless the creator fixes the broken stream link.

12. A moderator can delete invalid reports and edit or delete database records that were reported by registered users, but can do only this for randomly assigned tasks (not for all records in the database.)

13. Complaints about invalid stations will employ a CAPTCHA for rate limiting, to prevent abuse of the complaint mechanism.

14. Moderator activity logs will be retained, and deleted records can be recovered by a member of the administrators group.

15. Registered users can notify the moderators group about malicious moderator activity, and moderators can flag malicious accounts for administrators to investigate or delete.

16. Moderators will initially be rate limited to resolving one issue per week. For any week in which a moderator action was performed without a dispute, the maximum number of actions which can be performed in any future week will increase by 1.

17. The user profile will record the number of valid entries which the user has created. For each valid station, the maximum number of moderator actions which can be performed in one week will increase by 1.

---

Many of us are willing to maintain station profiles, but do not have time to create new database entries just because the stream link broke. I believe this system would solve that problem. I also think it would make vandalism difficult and ineffective - so the end result is that we do not have so many broken streams.

FEATURES & BENEFITS

• Admin does not need to recruit or authorize moderators.
• A moderator would have to perform legitimate work in order to gain more power. They cannot do significant damage to the database in a short period of time. Malicious edits could be detected quickly, and easily reversed. A moderator account would be of little use to a vandal.
• A malicious moderator would not be able to target specific stations because issues are assigned to moderators on a random basis.
• A malicious registered user would not be able to target specific stations because they cannot create a new database entry with the same call sign or stream link of an existing record.
• Malicious new database entries or updates would be detected earlier and can be handled without administrator intervention.

[louis77]

As a creator of a radio app running on elementary OS which relies on radio-browser.org I found this issue because I see a lot of duplicate radio stations which could be removed to clear up and improve the quality of the directory. There are many good ideas made here but as far as I interpret @segler-alex notes, any moves in opening up the directory for edits just creates a whole bunch of new problems.

@kekukui proposal is great however implementation of such a system is a huge undertaking. So I also understand that @segler-alex may not have the time to implement such a system.

Legal questions not to mention. Today's legal situation especially in Europe and in the current situation with all the censorship going on is very confusing and clearing this up would cost a lot of money because this is something only a global law company could do.

So how do we move on from this point forward?

There are many developers with good intentions using and trusting radio-browser.org and there is currently no way for @segler-alex to trust anyone of us. So what I propose is that we create a GitHub hosted repository with diff lists of radio stations. I.e. a list of stations to be removed (duplicates, broken) or edited (correction of some fields).

Developers could then choose to use these diff lists and integrate them into their apps. This would relieve @segler-alex from any kind of responsibility. The GitHub repo will be a community project with a CC license so any entity wanting to complain can do so by making PRs to this repo and it will be fully independent from radio-browser.org. A trusted community of reviewers (probably app developers with a proven record) will merge the PRs and a monthly basis or so.

So what do you think? I'd say my approach is something that could be easily started immedately and @segler-alex will have more time to think if and how he will perhaps use this data to improve tha quality of radio-browser.org without building a huge approval system or opening himself up for legal issues.

FEATURES & BENEFITS

• absolutely no work for @segler-alex
• no legal implications for radio-browser.org
• we can start immediately
• easy to implement for app developers
• anyone contributing via PRs will be publicly visible on GitHub and takes responsibility of his/her own contributions
• builds a trusted circle of app developers who want to move forward and take some time and responsibility without having @segler-alex to make any decisions whatsoever

[wolterhv]

I think models like that of OpenStreetMap can be followed here. OSM is a far larger project and has a collaborative model. I use it quite often and I have yet to see vandalous edits. OSM has a wiki page on Vandalism though, which I think can be a good reference in this situation.

Perhaps it is not a bad idea to decouple the database from the platform. Platform developers can focus on improving the software and database managers can focus on keeping a clean database. The model for an open radio station database + api that @segler-alex has created here is what holds the greatest value in this ecosystem, IMO.

Moreover, it could be useful to let the user pick a database of choice, and thus let other databases exist and rise or fall according to their perceived value; this creates incentive for a database owner to maintain up-to-date and vandlism-free data. In this model, radio-browser.info would be one of the databases a user can pick, and radio-browser.info clients can let the user select which database they want their radio stations from.

Each database would be free to implement their own protocol for how vandalism is controlled. One of the protocols could be the one proposed by @olaf4, which although seems very sensible, might be a lot of work for @segler-alex to implement.

Is there anybody here who would be capable of hosting one of such databases?

[segler-alex]

As we are now 1 week away from the shutdown of the old radio-browser server at www.radio-browser.info/webservice I did add a "future plans" section to the FAQ to put out my thoughts to the internet. I post this here and hope you read it because it does affect this discussion. The short term plans are already mostly implemented, but I am still looking for a stream owner to test it with. I hope you like it or if not discuss it here further. FAQ is on http://www.radio-browser.info/gui/#!/faq

[nyouna]

Hi

I just discover this great project and just added a new station and wanted to do some edit on what i saw (clean-up) and just found this open issue.

@segler-alex I completly understand your concern about vandalism. it is a real issue and someone that really want to vandalism the DB will always find a way. As far as I know, the best why to prevent consequences of such behavior is:

• to prevent automatisation of each changes (captcha for example)
• to make each editor to register in a way it will cost to much to automatize it (with activation email + captcha + non temporary email address)
• to identify the change maker and save all the version of a record: this will allow to recover in a simple and fast way
  • by reverting all changes of specific users
  • to allow banning users that vandalism the DB

With these things done the DB will be safe enough and even if one find a way to vandalize it, his changes will be able to be cancelled in 1 click.

WDYT?

[Bulwagga]

This may rub some people the wrong way, and it would not prevent vandalism, but here goes. I want to update a station entry, so I send a check for $5 to the moderator. The moderator then opens a temporary link for me to edit the station entry on the web. Say a time window of a week. At the end of the week, the moderator then closes the link, checks the entry, and updates the database with the new entry. This gives a revenue stream to the developer, gives everyone a chance to keep the entries up to date. Monetizing open source.

[m-p-3]

What's the proper way to submit an edit request for let's say a broken favicon for a specific station? It's not exactly important playback-wise but it does make the whole thing more polished.

For example https://www.radio-browser.info/#!/byname/CHGA%2097.3 favicon could be updated to point to https://www.chga.fm/app/themes/webit/assets/img/logo__app.png

[GK90519]

This is a bust, I contacted this Selger to edit a stream and have not gotten any response.

[louis77]

Unfortunately I get also a lot of user feedback about bad data quality, broken favicons, broken streams, station that are in the system up to 20 times with false countries etc.

I'm on the verge of building a fork of radio-browser with community editing capabilities. Otherwise we risk loosing the trust of our users and reputation for the work we put into our apps.

[segler-alex]

i understand your problems, but this is only a hobby project, it always was. i am also doing programming without help, so if you want to contribute, i am very happy to accept pull requests. i hope everyone here knows already the story why i disabled editing. bad people are on the internet. so i decided make a system that is more automatic, do what programmers do best, try to find automatic solutions, instead of manual labour. i extened the standard for streams, added basically more http-headers https://www.stream-meta.info/version_2_headers.html then i implemented this on the backendside, so now every stream owner can add their own information and it will be kept up to date always. the stream owner is the one who knows best what his stream is all about. the problem currently is many of them do not keep their data up to date in their own software. now i gave them an incentive, that they keep it up to date, because it is used by the indexer every day.

i know i get change requests from people who want me to change a stream, but as i said, i do not like manual labour. i designed this system to improve the current condition. i want to innovate. find better solutions than people manually editing, a stream should be self contained and have all the information about itself. the next step would be to try to get in touch with distribution platforms or software vendors, to add this headers by default. for now people can also add https on their own streams. this should be possible everywhere. even without special software support.

the next big problem i want to solve is to find an AUTOMATIC way of removing multiple database entries that reference the same stream without user intervention. Do you have any ideas how we could handle this? i can find most double streams easily by just grouping streams by url in the database.

you are free to fork the whole thing, i designed it to be free and open source. but i ask you to try to improve the platform together. help is always appreciated. there is a catch, i will never use my time to change database entries manually, i think programmers should use their time to improve workflows. maybe the documentation for stream owners needs improvement https://www.radio-browser.info/#!/owners there are a lot of radio indexes out there in the internet, i always wanted it to be different, not only to be completely opensource but also innovative in some ways.

i hope you understand me now better, i actually pay all the infrastructure out of my own money, i do not get anything out if it but the fun of programming. i do not complain, i like it. but i want to design something good, something that brings internet forward.

if you have ideas to contribute or want to help with code, i am very grateful.

[louis77]

Hi Alex

Thank you for your detailed comment. I understand your point of view and I agree in that an automatic solution is always better than manual editing. Especially if there is nothing to gain from it. Radio-browser.info is a great project and many rely on it.

Some may believe that when you make something like radio-browser open for public use, there is also some responsiblity that comes with it. Others believe that this is a completely voluntary free effort and there is no obligation whatsoever from the developer/maintainer to the public. But let's not be distracted by this classic discussion about FOSS.

Reality might give us some hints: Afghanistan now counts 212 radio stations in the database. Only about 5 of them are actually from Afghanistan. It must be assumed that Afghanistan is the "default" that was selected when they filled out the form and did not select any country. Now you might argue that this is the fault of the person who inserted the record. Maybe. On the other side, it is the App developers that get feedback from the users that the data is plain wrong. And we have to somehow explain to them, that we can't do anything about it because of #49. Indeed I spent weeks to develop my app to contribute to a free radio community, like you do. Yet, I'm unable to make (or even request) a single change in the database.

There are many developers who would love to spend at least some time to increase data quality. Nobody is arguing that you have to do anything yourself. But it is not to be expected that those ~200 radio stations listed under the country Afghanistan will hire someone to modify their streaming software to send the correct meta headers to update their entry.

I made a proposal a few months ago, right here in this issue: https://github.com/segler-alex/radiobrowser-api-rust/issues/49#issuecomment-662495924

It was completely ignored. At least we could have had some discussion about how to solve that. Being it the naïve way I proposed or any other way. This is not about coding, it is about a strategic decision that you should have to make. You hold the keys to the database and it is clear that the effort to just fork the project will not help make things better. It would take months if not years to promote such a platform and receive actual edits. Time better spent to revise the data editorially.

But if you deny everyone access to data edits including yourself, how should we solve the "Afghanistan" problem, as an example? Should I learn Rust (sorry, Gopher here) and submit a PR which runs a UPDATE stations SET country = 'US' WHERE country = 'AF' on the next deploy? What exactly do you have in mind by asking us to contribute but at the same time deny access to the data?

If it would be my decision I'd ask some of the developers using the radio-browser API if they would be willing to spend a few minutes every month to edit data in exchange for using your infrastructure for free, if someone requests it. Then put a link to the GitHub Issue template on radio-browser.info and allow access to these developers to the data in any way. I'm sure that after a while interesting ideas will come up on how to automate that process in innovative ways. In the end, we all prefer to code.

But trusting some of the loyal users/developers of your API goes along with it, naturally.

— Louis

[Suplanus]

the next big problem i want to solve is to find an AUTOMATIC way of removing multiple database entries that reference the same stream without user intervention. Do you have any ideas how we could handle this? i can find most double streams easily by just grouping streams by url in the database.

I think you do the following:

• Group same url
• Use only these with icon, check the resolution for the icon and score it (0-10)
• Score the fields how important they are (state is 1, language is 3 and so on)
• Use the station with highest score

[GK90519]

It's a shame that this is "just a hobby". Seems like a good alternative to Tune-In. I found this on Kodi. If ya can't edit a stream, I would just like one removed so I could re-post it, please (CFRU 93.3FM Guelph)?

[kousu]

What about adopting some of the anti-spam measures from other projects, like CAPTCHAs, rate-limiting by IP, hashcash, or adding human moderators? And if we start to collect a database of good and bad edits, then we could use bogofilter (it's meant for email but works on any text stream) to speed up the filtering.

I detailed a bunch of the options in: https://github.com/segler-alex/radiobrowser-api/issues/39#issuecomment-488010870

[kousu]

@louis77 I'd be willing to work on a fork with you with more scalable abuse handling.

[stemy2]

I understand your problem, but disabling the ability to edit station replace the problem by another rather than solving it: the database could quickly become full of obsolete entries, making it unusable.

The "solution" i found for entries that have changed their datas is creating a duplicate entry with small change in the name so the station stays usable.

[louis77]

@louis77 I'd be willing to work on a fork with you with more scalable abuse handling.

I'm on board. Let's do this.

[DIWesser]

@louis77 I'd be willing to work on a fork with you with more scalable abuse handling.

I'm on board. Let's do this.

I can't code, but if you need someone to sift through the data and make corrections, I'd be happy to help.

[Moilleadoir]

It’s disappointing that the large amount of goodwill shown in this thread has been discarded. I can understand @segler-alex being wary of taking on any extra work, but that could be solved by just allowing a couple of trusted people (e.g. other app developers) to take on the work of managing trusted users. It wouldn’t have to be a completely open system like Wikipedia or OpenStreetMap to work more effectively than it does now.

Yes, there are bad people on the internet, but there are a hell of a lot of great ones too.

[louis77]

@Moilleadoir We are a small group of developers who are unhappy about how this issue was or wasn't handled, and we forked the project now. Our goal is to improve the data quality with manual moderation and allow editing of station data with a simple Git-based workflow while staying 100% API-compatible with radio-browser.info.

Come and join. Every contribution is appreciated. https://github.com/tunerapp

[GK90519]

@Moilleadoir We are a small group of developers who are unhappy about how this issue was or wasn't handled, and we forked the project now. Our goal is to improve the data quality with manual moderation and allow editing of station data with a simple Git-based workflow while staying 100% API-compatible with radio-browser.info.

Come and join. Every contribution is appreciated. https://github.com/tunerapp

So is this an alternative to radio-browser? I myself have been wanting to get a link corrected (CFRU Guelph).

[kekukui]

@segler-alex : i want to innovate. find better solutions than people manually editing, a stream should be self contained and have all the information about itself.

I understand - but some stream owners will not create the metadata. In some situations, apps like SMplayer, youtube-dl and VLC can resolve a stream URL from the page URL. So I think stream detection could be more automated in the future. Artificial Intelligence could also improve this... we have a big data set here and could probably train an A.I. to do some of the maintenance by watching human creators & moderators.

the next big problem i want to solve is to find an AUTOMATIC way of removing multiple database entries that reference the same stream without user intervention

I think that is a tall order because you need to train the A.I. first (unless the station is assigned to a specific maintainer.) For now, I think the next best way is to prevent those multiple entries from being created, and my proposal describes a method for this:

(4) If the stream URL in a new database record matches the stream URL in an existing database record, and the existing stream URL works, then the new database entry will not be accepted. (6) If the original metadata is wrong, registered members can flag a database record as invalid in the mobile player app. When a consensus is reached (according to some predetermined ratio), a bot will remove the entry if necessary, and someone can create a new record.

You could also create a desktop browser extension so the user would press a toolbar button while viewing a web page that contains the embedded stream URL. It could be similar to the Yatse or Kodi Core apps, the Play to Kodi browser extension, et cetera. The stream URL would then be detected and a new station data entry form would open with as many fields completed as possible to auto-detect.

the next step would be to try to get in touch with distribution platforms or software vendors, to add this headers by default.

I think this is a good idea, but it will take some time for that to become standard practice. I agree that we should find some way to apply innovation / standardization / automation here. But right now, this is the only free radio database of any useful size, and we need a better way to maintain it. We thank you for creating the largest open stream database in the world. And that is why it requires a group of moderators now. If a moderation system can work for WikiPedia, I think it can work for us. We should not allow this excellent resource to become unmaintainable and disintegrate, or else we may lose the opportunity to promote those standards which you want to establish.

there are a lot of radio indexes out there in the internet, i always wanted it to be different, not only to be completely opensource but also innovative in some ways.

I think it is an innovation because it has grown to be the largest stream database... and that is why it presents an opportunity to promote a standard API. It now enters a new phase of development where we must determine the best way to manage growth. As the old saying goes, "the show must go on."

i actually pay all the infrastructure out of my own money

This is why it is so disgusting to see that Odio client app become closed source -- the developer deleted his GitHub repo and renamed the app Strimio...

...and now he is charging $60 US per year to store a list of the user's favorite stations on a server somewhere !!! I think this guy should contribute to the cost of hosting the database. The web site says "Strimio is a free cloud-based streaming service" -- but Strimio is not providing the service! So maybe the open source license should include the following condition:

All client applications with a graphical user interface that utilize this database must include the following statement somewhere within that interface, such as the Help | About menu :

"This application uses data from the RadioBrowser service at {URL}"

---

@louis77 : implementation of such a system is a huge undertaking

Well maybe that full stack developer who is profiting from this project could do it for that price of $60 per user / per year!

If it would be my decision I'd ask some of the developers using the radio-browser API if they would be willing to spend a few minutes every month to edit data

Since all of the client apps need some improvement, I do not think we should burden open source application developers with moderation tasks. I believe we can distribute these tasks among the users: for example, how many registered users would be willing to validate one contested station edit per day with an approve/disapprove button in the mobile app? Crowdsourcing is the solution -- at least until we have an A.I. (or the project becomes financially endowed and self-sustaining somehow.)

[Porkepix]

the next big problem i want to solve is to find an AUTOMATIC way of removing multiple database entries that reference the same stream without user intervention

I think that is a tall order because you need to train the A.I. first (unless the station is assigned to a specific maintainer.) For now, I think the next best way is to prevent those multiple entries from being created, and my proposal describes a method for this:

(4) If the stream URL in a new database record matches the stream URL in an existing database record, and the existing stream URL works, then the new database entry will not be accepted. (6) If the original metadata is wrong, registered members can flag a database record as invalid in the mobile player app. When a consensus is reached (according to some predetermined ratio), a bot will remove the entry if necessary, and someone can create a new record.

I think this idea can have its own issues. First, simple rules could be applied at least to merge stations. Due to the fact it is currently impossible to fix mistakes in stations, people created dupes as a workaround. Second, your fix proposal to flag and remove stations with wrong metadata, as you deny the possibility to create a dupe would create times where a station would simply not exist anymore in the DB. Also, you talk about a mobile app player as if there was an official one, which afaik isn't the case.

---

As for having everything in the stream metadata, while it can't cover everything I think it's a great idea but, I hate to be pessimistic, but I think many commercial radio owners would never do anything that could take their users away from their own application or website due to the simple fact many of them sadly rely on tracking and ads as an income source, so having their users elsewhere might be a loss of income for them. It needs to have some usefulness for them to do so.

Crowd sourcing have shown the way especially for translating platforms, I believe the same ways could be safely used to maintain this DB :)

[Bulwagga]

the next big problem i want to solve is to find an AUTOMATIC way of removing multiple database entries that reference the same stream without user intervention

I agree that this problem could be solved as a computer science problem, but in practical terms I believe it will be solved first as a business process problem. There is no harm here in pursuing both lines of attack. As a computer scientist I would love to see an AI solution, as a listener I'd like a solution tomorrow.

There may also be some opportunities for new business models here... If micropayments from listeners went back to streaming sources, those streaming sources would have a solid interest in keeping the database accurate.

[kekukui]

@Porkepix

I think this idea can have its own issues. First, simple rules could be applied at least to merge stations.

Yes I agree... but just to clarify: a "duplicate stream" constitutes a dispute about which database record is most accurate. In my proposal, this dispute would be resolved by a vote of some quantity of registered users who agree to moderate. They would compare the two database entries and approve or deny the change. (This could be as simple as a pop-up on your phone.)

Due to the fact it is currently impossible to fix mistakes in stations, people created dupes as a workaround.

You can also regard a station edit as a duplicate stream because they could be correcting an error in one field of the original database record. But all of this only applies to stations which have no active maintainer: The strength of this system is that most of the people who created a database entry are willing to maintain it. We only need the vote in cases where there is no active maintainer or the validity of a database record is challenged by registered users.

This kind of moderation system would impose an extreme rate limit on malicious edits - and that would result in rapid deletion of the offending user accounts. This makes the database an unattractive target for vandals - so the amount of labor for moderators should be minimal, and the accuracy of crowdsourced metadata would continually improve. I present here the specifications for a new kind of distributed/crowdsourced moderation framework. It is a first draft, it may not be perfect, and I do not expect to see it implemented entirely here - but I believe that any discussion about how to scale in a distributed fashion is productive, because the conversation will often inspire people to think of other solutions.

you talk about a mobile app player as if there was an official one

I thought this was the official one https://f-droid.org/packages/net.programmierecke.radiodroid2/

many commercial radio owners would [never support this]

I propose that commercial radio station owners should insert ads which are geo-targeted to the listener's IP and this will be a new revenue source. Maybe RadioBrowser could even become an ad-broker! But the one thing which makes RadioBrowser great is the ability to create new database entries without moderation (and without delay.) That is why the database has grown so fast.

---

@Bulwagga I completely agree with your previous post.

If micropayments from listeners went back to streaming sources, those streaming sources would have a solid interest in keeping the database accurate.

I also wonder if some aspects of Brave's micropayments model could be replicated here: https://cryptoslate.com/worlds-250th-most-visited-website-reveals-bat-contributions-analysis-whether-brave-browser-can-replace-ads

[Porkepix]

you talk about a mobile app player as if there was an official one

I thought this was the official one f-droid.org/packages/net.programmierecke.radiodroid2

As far as I know, it's just one API users among many others: https://www.radio-browser.info/#!/users A popular and probably more known than others one, but this isn't official in the way it's not linked to segler-alex. It's a recommended one though, as you can see.

many commercial radio owners would [never support this]

I propose that commercial radio station owners should insert ads which are geo-targeted to the listener's IP and this will be a new revenue source. Maybe RadioBrowser could even become an ad-broker! But the one thing which makes RadioBrowser great is the ability to create new database entries without moderation (and without delay.) That is why the database has grown so fast.

@Bulwagga I completely agree with your previous post.

If micropayments from listeners went back to streaming sources, those streaming sources would have a solid interest in keeping the database accurate.

I also wonder if some aspects of Brave's micropayments model could be replicated here: cryptoslate.com/worlds-250th-most-visited-website-reveals-bat-contributions-analysis-whether-brave-browser-can-replace-ads

Please, this is one of the rare places on the Internet free from the attention economy (my translation might be inaccurate, I'm not an English native) and other ad and tracking based revenues. Keep it free from it (though some stations have ads inside their streams anyway).

[kekukui]

@louis77 : Our goal is to improve the data quality with manual moderation and allow editing of station data with a simple Git-based workflow while staying 100% API-compatible with radio-browser.info.

Come and join. Every contribution is appreciated. https://github.com/tunerapp

Maybe you should not fork the database until you have cloned the interface. But in any case, I think you should enable the Discussions feature on one of those repositories, so the conversation about how to scale can progress there.

[aha999]

RadioGarden seems to battle this issue by using a station submission form, and changes probably need to get approved.

[JensKorte]

How about creating the list as a git project where people create a github account, create new entries and do pull requests? A core group would moderate the requests and check the entries. The edit history will be public. If you realize someone creates bad content, the old requests can be double-checked.

[skrew]

This project have to stay alive ! I have imported the DB and patched the DB on my own to uses it in my APP.

I've just done a python script for:

• Remove duplicate
• Clean the tags list
• Clean the language list

We need to have a fixed list of tags and language and, it's not a new feature, the edit to be back...

Keep up !

[conradfr]

Hello,

The way I see it it needs an admin interface. Probably in a separate project so it could be done by someone else than @segler-alex and/or not in rust.

• It would have moderators (you could start with people using this api in open source projects)
• Modification requests would be put in a queue and reviewed by moderators.
• It could have a merging tool for duplicated radios, both from checking potential duplicates and actually merging them.
• It could have automatic checks for pictures/favicons and streams (that's what I currently do when importing from the api) to help spotting outdated/erroneous data.
• Other things I have not thought about :) I know for example that it would be great to update all stream urls to https when possible, as it's a problem if you use this api in a web app (calling http urls from a https site is disabled nowadays).

Duplication is a real problem. For example the top French radio is duplicated 18 times (!), and only three have a working logo / favicon.

edit: and it would log every action by people of course ;)