RFC: any plans to join forces with greasyfork?

[isync]

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.

[sizzlemctwizzle]

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.

[JasonBarnabe]

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?

[Martii]

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.

[isync]

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.
Peer2Peer is probably the more up-to-date way to go, okay with me, as I am not on the programming side of this project, having all these sync/dedup issues...
My naive first idea was: let's get ego out of the way, and decide for one project to be lead, the "central" site, and the other site(s) becoming mirrors, with their own UI if they like.

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.
Thumbs up for both efforts, especially now with userscripts.org being down, again!
Still, I hope I could give some cues.

[jesus2099]

It’s a pity we end up having two sites indeed…
IMO github would be enough if it allowed tagging files (we could tag as userscrtip, thissite.com, thatsite.fr, etc.). It would be the best solution.
I like the simple html pages and the fact that greasyfork categorise scripts automatically by their includes (but it should only treat domain.tld, not server.domain.tld imo, too many splits) rather than having to set a category/groups (or tag) manually.
I like the name of openuserjs more though.
I don’t know why but openuserjs is older in github but greasyfork has more scripts…
It’s only my average comments…
My feeling is even more abrupt than isync…rather than two sites, i’d like one site… it’s very selfish… sorry.

[JasonBarnabe]

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.

[jerone]

I would prefer to implement both sites their own oauth servers at one point.

[studgeek]

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).

[isync]

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.

[jesus2099]

Sorry for useless chat but i thought some supportive comment is never bad.
Now that i have used both sites for some little time, and thanks to them being front-ends to a common github (or anything else for gf), i really like those two sites !
It’s so much more convenient than userscripts.org was !