RFC: any plans to join forces with greasyfork? #96
Comments
|
Jason Barnable has already agreeded to implement an API that has yet to be defined (#77) that would allow both sites to share script information. It would be nice to have a central storage but Greasy Fork uses SQL to store script info and OUJS uses MongoDB. OUJS stores scripts on Amazon S3 and I assume Greasy Fork just stores them on its server (I could be wrong). I wouldn't be opposed to sharing a central repository of scripts, but it's up to @JasonBarnabe if he wants to go down this road with us. |
|
From a technical perspective, a central repository basically means creating a third "thing" that would have to be supported by one/both/all parties involved. I don't really see the benefit to doing that when you could realize the same benefits with a peer-to-peer setup. Essentially, each site would implement an API that the other could use to grab/sync. This is pretty easy to do technically from the provider side, just pick a storage format (JSON) and output all relevant properties of each entry. From the consumer side, you have to deal with potential duplicates and such, which is harder but still doable. I think what would require some thought is how to determine which scripts will be shared. I've had a site copying styles from userstyles.org. Initially it was copying everything, but eventually switched to copying just where the posted license permitted. Even so, people were not impressed, and some even changed the license on their styles to prevent it from happening. Our situation would be different in that it would be a sharing of content rather than one site leeching off the other, but I still think some people may object to their scripts being propagated from one site to another, even if the license they specify says it's OK. Others might be OK with it even if the license on their script would say it wasn't. So maybe this would have to be opt-in rather than sharing everything by default? |
+1 here if sharing comes to fruition with this provision. My concern would be that technical support of a user.js would still need to be on minimal sites so opting in would probably need account owners to be on both ends to enable this sharing. |
|
With all your input, I now see it's more difficult than I first thought it would be. The "third thing" issue:Yes, agreed, that would be the outcome. Like the central PAUSE server CPAN uses, where everyone uploads releases, and this repository is then displayed by CPAN and the more recent metacpan, each with their own style/UI. Even with two sites + userscripts.org I'm already asking myself: next release, which site, and what to put into the metadata block as "updateURL"... Second, the "propagation discrepancy":I didn't think of that! I was approaching it from a perspective where I want maximum exposure for my scripts. Giving it a restrictive license was not on my list. But I see the point, for example when the repository is scraped by some malicious, badly behaving site, confusion users, probably using a valid script to trick users into installing malware with valid scripts as bait... Third, either SQL and Mongo seem limiting:I've always felt the additional metadata-entry on userscripts.org to be a pain. It was always out of sync. Why can't we just have self-contained releases, and the repo or script-site takes its data from there. archive.org employs a simple "one release one directory" approach - and they know big storage. Transferring it into SQL/ Mongo/ or some inverted index - makes sense for indexing/searching, but not really for a repo, me thinks, as it locks data in. Let's define a release-bundle format. With some meta-data-file telling a displaying site everything that's not already in the script's header or can't be put there, like screenshots or longish text (like this here). And with a dumb non-db repo, we could store scripts on a dumb "third thing", even here on github, as long as github is the go-to code hosting site. Please excuse this long post. You guys have better things to do. |
|
It’s a pity we end up having two sites indeed… |
|
One addition to what I posted above... There would need to be a way for a user on one site to "claim" the scripts relating to an account on another. With userscripts.org, I made it so the user had to include their Greasy Fork account URL in their profile. We could do the same thing, but instead of putting it in public place, it could just be fed into a separate JSON feed. |
|
I would prefer to implement both sites their own oauth servers at one point. |
|
I think the best approach for the script data itself is to do a github based approach like many of the new package managers (homebrew, npm, etc). That gives you a github identity, voting, issues, and makes it easy for developers to suggest changes. If the repositories can agree on a common structure in github for the script and its metadata then the developers can just submit the github link to both. Then the repositories can just pull the data they need. You can use a extensible json format for metadata so repository specific flags can be set also (like npm). |
|
As much as I think github as "third entity" in the mix makes sense, I'd like to stress that github is not a charity. Let's not carve our bindings to it in stone. So if we go down this path, let's make it a plug-in - so we can switch to some other dumb-hoster once (if ever) github decides to go to the dark side. That said: userscripts.org is reachable at port 8080, so jump ship with your script or use this window of opportunity for a quick backup. |
|
Sorry for useless chat but i thought some supportive comment is never bad. |
|
I've done some thinking about how integration of third party scripts (like those from greasyfork) would be handled on OUJS. To support our method of searching, I think we'd store the script as if we had imported it. Of course the install button would still point to the original source, and the source would be loaded dynamically on the view source page (we'd never store the source like we do when importing from GitHub). I'd like to register for a callback when a script we've imported updates in any way remotely. And I'd like to be able to provide some sort of secret identifier of OUJS to the script listing JSON page (https://greasyfork.org/en/scripts/redistributable.json on greasyfork), that would list scripts not imported yet. For script support I think we'd point back to the original site (no issues tab on OUJS). Author links would do the same. Since we both have our own forms of moderation the hosting site would just point back to the sharing site (information like this needs to be provided in the feed). Obviously we'd implement this same system for OUJS if it can be agreed upon. The only problem we'd have with this on OUJS is that the third party scripts could potentially violate our TOS on licensing. Perhaps other sites (greasyfork) could ask their users if a script is licensed under an OSI license, and if not, are they willing to release it for redistribution under the MIT license. Greasyfork already has a checkbox for redistribution but I don't think that is enough for the level of integration I'm suggesting. What do you think @Martii? And is this system of sharing something you'd support @JasonBarnabe? I just don't think providing JSON feeds of script information is enough. The site pulling information has to keep track of everything. How would I integrate GF search results, or even ordinary listings, properly into OUJS results? I fear third party scripts would become second class citizens. |
In general you can do what you wish with the scripts in there. They're not mine, after all... |
With all Code there is implied Copyright and base licensing but whether or not an author at GF chooses an OSI one is up to the author. GF has, whether it is liked or not, an implied redistribution license for at the minimum usage/redistribution on GF otherwise Copyright is violated and not leveraged with a license. Since OUJS has OSI based modeling, any script that shows up with a non-redistributable license should get removed from our linkage in entirety and also if it's not OSI approved. @JasonBarnabe will need to make a formal email declaration/statement to @sizzlemctwizzle in email (email replies should be archived and can use email GH responses to make these things public to prevent tampering) stating exactly where in what API it is allowed for extending his site licensing to ours and the original authors... and freeze it... if it ever becomes unfrozen another email agreement needs to be done and reworked/refactoring to proceed. Same goes in reverse... GF will need to check with the source repo, in this case us, and if the licensing is tampered with they should terminate that script and/or account. All of this is a rather large moderation/administration chore just as a FYI regardless of automation. I've already noticed on GF that it doesn't appear to have a default license which opens up @JasonBarnabe to more DMCA and other Copyright infringements e.g. TDN's ... so it might be wise for that site to choose a default. As far as blotting out specific features, like issues, that is fine and keeps the noise level on the appropriate site... OUJS should still maintain a flagging system in case moderation/administration needs to remove the script and/or user.
But you are the host redistribution for those authors and that liability can't be shirked. Hope some of this makes sense as legal issues/informations are a pain sometimes. :) |
|
By callback, I meant notification. Kind of like how GH handles webhooks. Yes, you use the identifier to maintain state for us on your end. Parsing license data to determine OSI compliance would be very unreliable.
|
|
I think a webhook-like notification may be overkill to start with. I think it's better to start with something a little dumb and see what makes sense after that. I still don't understand what this secret identifier would do. You'd have a list of scripts you've imported, you'd have a list of all available scripts to import, so wouldn't it be simple to get the list of scripts not imported? If you're concerned about having to go through all the pages of scripts, then maybe instead I can add a feature where you post the list of scripts you don't want to see in the results. |
* Adopted similar block from `slow!` * Re-factor libraries. * Few bug fixes in re-factorization * Some relocations * This should allow existing collaboration, icons, and a plethera of most Userscript features for Libraries a.k.a UserLibrary Applies to OpenUserJS#96 and a bunch of others... too many to itemize.
* Adopted similar block from `slow!` * Re-factor libraries. * Few bug fixes in re-factorization * Some relocations * This should allow existing collaboration, icons, and a plethera of most Userscript features for Libraries a.k.a UserLibrary Applies to #96 and a bunch of others... too many to itemize. Auto-merge
|
First step towards this goal is to get GF a little clearer for dispute resolution. Currently there is an outstanding dispute, on our site in private, on whether a certain script can be "reposted elsewhere". Firstly and unfortunately your site doesn't give a human readable value for "No License" (you should read all of those pages too to get a better, or refreshed, understanding) and your default of "N/A" (we've briefly chatted about about this before with GMC). e.g. if one selects "I'm OK with my script being reposted elsewhere" vs "I don't want my script being reposted elsewhere" ... they both show "N/A"... which is extremely unhelpful. Please note without the next item even you can't advertise/store the script.... which you are doing more or less. Secondly I have yet to find your TOS/TOU for the site and have been looking off and on since about July of this year (2018) both directly and through search engines. We need that to mitigate otherwise we can't effectively take action with a claim. This can be dismissed for insufficient information available... which I personally would rather avoid the drama of that. Userscripts are supposed to be enjoyable but the persistence of some needs to be addressed. Thirdly I am currently taking the word of our user as being the same as your user... this may not always be the case... this part is a little more difficult to manage especially when they don't advertise who they are. So... what we need as a barebones start is a clearer "guest" version of these first two items please... this includes "unlisted" script views with direct access. |
|
I'm elevating your account to moderator on OUJS for better communication for cross-site issues, if there are any, relating to the Graveyard. Please do not share this information publicly at this time like your site does (still haven't decided if that feature of GF is a good or bad thing... think retaliation). Been thinking about doing this for a while. Obviously you are busy with your own site so you don't have to flag unless you want to... but may help assist with bad actors cross-site. @sizzlemctwizzle we'll need to decide if there are additional privacy-security concerns to be addressed. At this time I don't see any and I'd still like to have the comment portion allowed to be viewed by Moderators but we run the risk of exposing users cross-site by how they comment. Pardoning is still handled manually at this time while I'm still kicking. And the code that allows moderators to remove should never be activated imho. |
* Can't do this anywhere else so symmetry Applies to OpenUserJS#96
* Can't do this anywhere else so symmetry Applies to #96 Auto-merge
https://github.com/JasonBarnabe/greasyfork
Any plans to merge, like quick, before all the central goodness of golden userscripts.org times explodes to more microsites...?
One idea, maybe, having a central repository of scripts, curated and displayed by two sites and user bases. So that greasyfork and OUJS are mere UI. A bit like metacpan and olden CPAN.
The text was updated successfully, but these errors were encountered: