Skip to content

Decide the fate of custom site/project prefixing in the UserScript metadata block #285

Closed

Description

@Martii

In relation to greasemonkey/greasemonkey#1963 I see 3 possibilities so far over the past few days to address an impending conflict with everyones project.

// ==UserScript==
// @run-at             document-end
// @namespace          http://localhost.localdomain
// @name               RFC 2606§3 - @license and @licence (recovered) Unit Test
// @name:de-DE         RFC 2606§3 - @license und @licence (wiederhergestellt) Komponententest
// @name:fr            RFC 2606§3 - @license et @licence (récupéré) Test unitaire
// @description        Tests out non-unique keys
// @description:de-DE  Tests, nicht eindeutige Schlüssel
// @description:fr     Tests de clefs non unique
// @copyright          2007+, Marti Martz (http://userscripts.org/users/37004)
// @license            GPL version 3 or any later version; http://www.gnu.org/copyleft/gpl.html
// @version            0.0.0
// @include            http://www.example.com/*
// ==/UserScript==

// ==OpenUserJS==
// @author Marti
// @collaborator jerone
// @collaborator sizzle
// @collaborator Zren
// @hash 131a5eddc53f4018d6b5ee76d8543cb3cb4e50fa
// @somefutureidea somevalue
// ==/OpenUserJS==
  • Has the disadvantage that any user.js engine may not read it. EDIT: ...but at the same time resolves any external conflicts and is in the spirit of optional collaboration instead of mutual collaboration.
  • OUJS could store the raw formatted metadata blocks text instead of the single metadata block Object... and a migration routine put in place or applied. EDIT: We should do at least the latter part of this anyways for Localized script name and description greasemonkey/greasemonkey#1963 support no matter what site/project prefixing we support. I highly recommend the former as well but depends on how we finalize the stored Object or not.

or

// ==UserScript==
// @run-at             document-end
// @namespace          http://localhost.localdomain
// @name               RFC 2606§3 - @license and @licence (recovered) Unit Test
// @name:de-DE         RFC 2606§3 - @license und @licence (wiederhergestellt) Komponententest
// @name:fr            RFC 2606§3 - @license et @licence (récupéré) Test unitaire
// @description        Tests out non-unique keys
// @description:de-DE  Tests, nicht eindeutige Schlüssel
// @description:fr     Tests de clefs non unique
// @copyright          2007+, Marti Martz (http://userscripts.org/users/37004)
// @license            GPL version 3 or any later version; http://www.gnu.org/copyleft/gpl.html
// @version            0.0.0
// @include            http://www.example.com/*
// @oujs.author Marti
// @oujs.collaborator jerone
// @oujs.collaborator sizzle
// @oujs.collaborator Zren
// @oujs.hash 131a5eddc53f4018d6b5ee76d8543cb3cb4e50fa
// @oujs.somefutureidea somevalue
// ==/UserScript==
  • Using some other character. Since the damage is done with the dash operator may as well continue with destruction. Not backwards compatible. We also might run into this situation again if one of the user.js engines support the character we already do.

or

// ==UserScript==
// @run-at             document-end
// @namespace          http://localhost.localdomain
// @name               RFC 2606§3 - @license and @licence (recovered) Unit Test
// @name:de-DE         RFC 2606§3 - @license und @licence (wiederhergestellt) Komponententest
// @name:fr            RFC 2606§3 - @license et @licence (récupéré) Test unitaire
// @description        Tests out non-unique keys
// @description:de-DE  Tests, nicht eindeutige Schlüssel
// @description:fr     Tests de clefs non unique
// @copyright          2007+, Marti Martz (http://userscripts.org/users/37004)
// @license            GPL version 3 or any later version; http://www.gnu.org/copyleft/gpl.html
// @version            0.0.0
// @include            http://www.example.com/*
// @oujs:author: Marti
// @oujs:collaborator: jerone
// @oujs:collaborator: sizzle
// @oujs:collaborator: Zren
// @oujs:hash: 131a5eddc53f4018d6b5ee76d8543cb3cb4e50fa
// @oujs:somefutureidea: somevalue
// ==/UserScript==

This entails extra coding to maintain the : because we won't always know if a key is a site prefix or a locale... so must pad using an extra :. Padding will need to be maintained.

Everyone, especially the maintainers at @arantius @johan @gera2ld @derjanb @OpenUserJs/admin @OpenUserJs/owners @OpenUserJs/backend @OpenUserJs/frontend and @JasonBarnabe, is welcome to participate in this team effort meta discussion as usual.

Please let me know if any other ideas are better, worse, ineffective, etc. :)

Refs:

Activity

  1. changed the title [-]Decide the fate of custom site/project prefixing[/-] [+]Decide the fate of custom site/project prefixing in the metadata block[/+] on Jul 29, 2014
  2. self-assigned this
    on Jul 29, 2014
  3. Zren commented on Jul 29, 2014

    @Zren
    Contributor

    Or manage stuff like collaboration on the website itself.

    #208 (comment)

    I say we axe it.

  4. added a commit that references this issue on Jul 29, 2014
  5. Martii commented on Jul 29, 2014

    @Martii
    MemberAuthor

    Or manage stuff like collaboration on the website itself.

    That is only a small piece of it. Moving collaboration to group structure doesn't address any other site specific metadata block(s) options... see the updated refs section above. The reason I made the request on userscripts.org (USO) for // @uso:hash is for integrity checks which USO and GM did adopt in a similar fashion with another purpose. I used it for backing up versions from USO in Count Issues. I'd like to see that here as well in another pr/issue since it is beneficial all around.

    I've already done a certain amount of the necessary migration routines depending on what way we all decide to go with site/project prefix options.


    See an additional marked EDIT(s) above too.

  6. johan commented on Jul 30, 2014

    @johan

    @Zren has a good point. If someone writes a malicious script and tag it as authored by Martii and publish it, that's not a good reason for him to get falsely accredited as that script's author.

  7. Martii commented on Jul 30, 2014

    @Martii
    MemberAuthor

    If someone writes a malicious script and tag it as authored by Martii and publish it, that's not a good reason for him to get falsely accredited as that script's author.

    This is #208 from above. It's easy enough to check if the user exists (which is why at least the collaborators are hyperlinked and there are already some safeguards in place) and check if the script exists under that users authors account. If it doesn't disable collaboration and/or prevent uploading. We can always pull the reference from the metadata block(s) retrieval too which is primarily what this issue is about here on OUJS. Administrative side if a moderator and up sees that someone or some script doesn't exist then the script should get axed currently or perhaps a gentle notice like I've already done once with @vBm. If a network of trust isn't solid then the source author shouldn't do this even with GitHubs collaborations. Same way GM allows Ventero to be unfettered. That is part of GM's network of trust.

    One could also use someone elses // @namespace http://github.com/johan/ or even just a general JavaScript comment too. The use case you mentioned isn't isolated to the metadata block(s). We do have some control over what's published and what isn't including tracking what was and what is. The benefit of cross-site development is a feature that a lot of us, including other users and authors, are striving for but there will be hurdles to overcome.

    We'll work on that soon but I think until then the fate of any site specific key needs to be determined in the standard metadata block... if "GM/GMP/TM/VM/anyone else" are going to be mutually collaborative or optionally collaborative... e.g. Do we hear that the user.js engines don't care about anyone else or are they willing to listen to common ideas. I appreciate your input though as I know you have gone between Scriptish and GM in the past and definitely beneficial to the community as a whole.

    Me personally, I'm leaning towards the separate metadata block for our site to prevent any future conflicts and from what everyone else has been typing... but am looking for alternatives. If another user.js engine or another site wants to pick up on it then that is great. Cave monkeys beware of evolution! ;) :)

  8. added a commit that references this issue on Jul 31, 2014
  9. Martii commented on Oct 23, 2014

    @Martii
    MemberAuthor

    bump There's some options to decide in here that I've been waiting for some response in here. After some wait time with Zren and his efforts and some tinkering with the alpha some more most likely this is going to be tackled.

  10. Martii commented on Dec 2, 2014

    @Martii
    MemberAuthor

    Still awaiting... there are two trains of thought over the past few months... keep parseMeta as is with the object level bump as depicted in Meta View Alpha above (I seriously doubt there is going to be any major modification to existing @keys but one never knows)... the other is to use pegjs (or better) and modify just about every reference to retrieving the metadata blocks... which will increase the complexity of the MVC of OUJS as a whole.

  11. changed the title [-]Decide the fate of custom site/project prefixing in the metadata block[/-] [+]Decide the fate of custom site/project prefixing in the UserScript metadata block[/+] on May 1, 2015
  12. added a commit that references this issue on Jul 18, 2015
  13. 50 remaining items

  14. self-assigned this
    on Sep 2, 2015
  15. Martii commented on Sep 2, 2015

    @Martii
    MemberAuthor

    Reopened due to #729

  16. reopened this on Sep 2, 2015
  17. Martii commented on Sep 4, 2015

    @Martii
    MemberAuthor

    As previously announced yesterday... taking server offline for migration hump... see everyone on the other side. :)

  18. Martii commented on Sep 4, 2015

    @Martii
    MemberAuthor

    Back online... revalidating... on current master commit on production.

  19. Martii commented on Sep 4, 2015

    @Martii
    MemberAuthor

    Graveyard is not complete yet... so leaving open until I get this done... this is a bit more complicated due to mongoose requirements of sub-Objects and the virtual "reason" I put in with removerAutomated... so I'll probably do this next week... again it's not as critical at this moment so a slower time table can happen with this. I do not need to take production offline to do these.

  20. removed
    expediteImmediate and on the front burner.
    on Sep 8, 2015
  21. Martii commented on Sep 8, 2015

    @Martii
    MemberAuthor

    Graveyard should be complete.... also zapped that final script without source on sizzles account (This particluar issue was possibly somewhere around #633 based off most of the dates I skimmed over... don't know for sure). Closing as redone.

  22. removed their assignment
    on Sep 8, 2015
  23. added a commit that references this issue on May 29, 2016
  24. locked as resolved and limited conversation to collaborators on Apr 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CODESome other Code related issue and it should clearly describe what it is affecting in a comment.DBPertains inclusively to the Database operations.DOCPertains inclusively to the Documentation operations.UIPertains inclusively to the User Interface.migrationUse this to indicate that it may apply to an existing or announced migration.

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions