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