Closed thebrandonlucas closed 1 year ago
It is a good idea, we did discuss this on the Discord already and a few concerns were raised. @dadofsambonzuki @bubelov do you want to continue the discussion here?
It takes time and effort to implement and maintain such features, so it would be nice to figure out if that would add any value and if that added value worth the hassle. In my view, rating systems are largely ineffective and prone to abuse, and it's much easier to understand a label like "this place was last verified on xxx-xx-xx" than "this place has 4 up-votes" or something.
If someone has time to implement and maintain this feature, it would be nice to make it easily removable in case it proves useless or if there will be no maintainers.
It takes time and effort to implement and maintain such features, so it would be nice to figure out if that would add any value and if that added value worth the hassle. In my view, rating systems are largely ineffective and prone to abuse, and it's much easier to understand a label like "this place was last verified on xxx-xx-xx" than "this place has 4 up-votes" or something.
If someone has time to implement and maintain this feature, it would be nice to make it easily removable in case it proves useless or if there will be no maintainers.
Fair point, I definitely think it could be a more complicating than contributing feature if we're not careful, and it's probably not the highest priority item at this point. I was trying to think of ways to mitigate the outdated/bad information issues, and maybe we could think about an incentive structure that allowed tips to be given to people who verify/update/add locations instead of a rating system. If we did build such a system, we could build it in a modular way so as to be able to remove at will.
@thebrandonlucas
I was trying to think of ways to mitigate the outdated/bad information issues
We're basically a front-end to an Overpass query, so our data is just a slice of OpenStreetMap data set. This approach has some pros and cons, but one thing we shouldn't worry about is moderation, since all of our places are just plain old OSM places and OSM has a full history of all edits, as well as some moderation capabilities.
This is good for OSM because they get new places and some maintenance for free. It's good for us because we can benefit from their infrastructure and edits by non-bitcoiners. Replicating some of that infrastructure and merging our metadata upstream is not that easy, that's why I'm cautious of such things.
OSM is basically a Wiki for maps, nothing is stopping anyone from submitting their edits but the end result seems to be good enough. Most of our problems are due to outdated data, but it was perfectly valid at the time it was submitted. No one bothered to maintain this data set for years and the date of the last edit is a strong indicator of reliability of that data. That's why I think that survey:date can become a critical tool to assess the validity of our places and it can be good enough by itself. It's already OSM-native so we can get all the benefits listed above.
That said, one of our biggest bottlenecks is lack of funds for infra and editor time, so being able to boost place visibility with some kind of LN-donaton might be an interesting route. Say, a package which guarantees OSM data maintenance plus special visual distinction across all of our client apps. Just a random thought.
@bubelov That's great, helpful to know that we inherit a lot from OSM.
That said, one of our biggest bottlenecks is lack of funds for infra and editor time, so being able to boost place visibility with some kind of LN-donaton might be an interesting route. Say, a package which guarantees OSM data maintenance plus special visual distinction across all of our client apps.
This is interesting. So, in this scenario, the package could check the last updated date of a location, tips could be donated to the editor, and the special visual distinction would be based on how up to date the information is? Or would the visual distinction be based on donations somehow?
@bubelov That's great, helpful to know that we inherit a lot from OSM.
That said, one of our biggest bottlenecks is lack of funds for infra and editor time, so being able to boost place visibility with some kind of LN-donaton might be an interesting route. Say, a package which guarantees OSM data maintenance plus special visual distinction across all of our client apps.
This is interesting. So, in this scenario, the package could check the last updated date of a location, tips could be donated to the editor, and the special visual distinction would be based on how up to date the information is? Or would the visual distinction be based on donations somehow?
I was thinking of a more centralized approach where the project team promises store owners some goodies in exchange for small fixed or recurrent donations. Some shops might we willing to stand out visually as sort of project sponsors. Some OSS projects allow sponsor banner placements as a way to cover the infrastructure and other costs, but those are relatively big transactions which require some human involvement.
Paying editors directly might open the the whole data set to abuse, I think it might be easier to pick well-known individual editors from the community, and to ask them to maintain the data set part time or full time, if project has enough funds for that. Dealing with the approved editors and offering stable arrangements might be a more reliable option. Mapping can be hard to grasp and it might be more efficient to have a few dedicated professional mappers. The problem is, mapping is pretty boring, so a little financial incentive can certainly help.
Also, mapping is not the only cost. The project might need a beefier VPS for its own full node or an OSM instance, which aren't cheap to rent, so more centralized budgeting can be more effective.
Paying editors directly might open the the whole data set to abuse, I think it might be easier to pick well-known individual editors from the community, and to ask them to maintain the data set part time or full time, if project has enough funds for that. Dealing with the approved editors and offering stable arrangements might be a more reliable option. Mapping can be hard to grasp and it might be more efficient to have a few dedicated professional mappers. The problem is, mapping is pretty boring, so a little financial incentive can certainly help.
I agree that this may be an easier approach to manage, and possibly trying to pay editors directly could open up a lot more issues.
Do we see a path forward for something like this now @bubelov or is this more something we'd like to table and save for future development/discussion?
Hey @thebrandonlucas !
Sorry for being a little slack on this, things are moving fast right now!
In short, we definitely want to experiment and progress with some form of LN integration / incentivisation and we'd love your help in shaping and building this out.
We should probably jump on a call. Can we can talk later this week?
Are you on our Discord?
should probably jump on a call. Can we can talk later this week?
I probably won't be able to do a call until Monday at the earliest, and should be able to do any day except the 6th. Let me know what times work for you, and yep I am on the Discord! Excited to start building!
Currently, locations can be added without any sort of verification process and data may be outdated/irrelevant (see @nerd2ninja and @MajorMajor posts here. We could implement a Stacker News style tipping system where users can tip posts that are accurate, or pay to "downvote" posts that are inaccurate, providing some sort of validity score. This would not only help incentivize posting, but would help provide trust and give users easy recourse when they encounter inaccuracies. We could implement this via WebLN, and users could interact with the site via WebLN client such as Alby.
Further discussion would be needed to spec out the exact design. Happy to tackle implementation if we decide to implement!