Log in to your High Fidelity account to give feedback
Open Source Modkit
⓵ 𝙒𝙝𝙖𝙩: 𝘼 𝙁𝙧𝙖𝙢𝙚𝙬𝙤𝙧𝙠 𝙛𝙤𝙧 𝙈𝙤𝙙𝙙𝙞𝙣𝙜 We all want to see the High Fidelity platform evolve and grow… From an open source standpoint, however, it can be difficult to identify the best ways to experiment and contribute results. It would be great if development paths were made clearer, so that more people could extend the platform and maintain results in parallel. And in order to protect contributor investments, extensions would need compatibility with stock builds and better odds of working across releases. We therefore suggest creating a *completely open source-minded* “Modkit” to help foster such contributions alongside the main application code base. ⓶ 𝙃𝙤𝙬: 𝙃𝙞𝙁𝙞 𝙊𝙥𝙚𝙣 𝙎𝙤𝙪𝙧𝙘𝙚 𝙈𝙤𝙙𝙠𝙞𝙩 With High Fidelity’s assistance we would like to bootstrap the following project components: ○ https://github.com/highfidelity/hifi/tree/master/plugins/hifiModkit (proposed) — New built-in plugin ○ https://github.com/highfidelity/hifi-modkit-sdk (proposed) — New SDK and github repo ○ https://modkit.highfidelity.io (proposed) — New API/SDK docs An expanded version of the above is available given corresponding interest. ⓷ 𝙒𝙝𝙮: 𝙋𝙚𝙤𝙥𝙡𝙚 𝙒𝙖𝙣𝙩 𝙩𝙤 𝘾𝙤𝙣𝙩𝙧𝙞𝙗𝙪𝙩𝙚 Lots of people have imagined and several have attempted extension of the High Fidelity platform, only to promptly hit significant roadblocks. And while the existing codebase has a “plugin” concept, it is neither well-documented nor well-suited for *ongoing* development. 𝗖𝘂𝗿𝗿𝗲𝗻𝘁𝗹𝘆❟ 𝘁𝗵𝗲 𝗿𝗲𝗾𝘂𝗶𝗿𝗲𝗱 𝗲𝗳𝗳𝗼𝗿𝘁 𝗼𝗳 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗶𝘀: ○ Conventional HiFi Plugin: VisualStudio, VisualStudio Dependencies, Qt, vcpkg, CMake, generate & regenerate CMake, Python, GBs of Disk Space, lib/plugins, lib/shared, Hours of Time 𝗪𝗶𝘁𝗵 𝗠𝗼𝗱𝗸𝗶𝘁 𝗶𝘁 𝗯𝗲𝗰𝗼𝗺𝗲𝘀: ○ Modkit Plugin: C compiler + hifi-modkit-sdk․zip Paving the way for future enhancements that live longer and remain effective will require a stronger foundation; a foundation like Modkit, which prioritizes open source collaboration and support for externally-managed extensions. 𝗪𝗔𝗡𝗧𝗘𝗗: [ Valve Index Controller support | Space Mouse support | Avatar Shaders | Custom Initialization / Default Scripts | Business Productivity Tools | Domain Access controls | External Chat Integration | Permissions management | Alternative Editing systems | Expanded JS APIs | Streaming Audio integrations | Advanced NPCs | Inventory Systems | Internet-of-Things (IoT) bridges | Additional Multimedia codecs | … ]
(Pitch) -EntityFilterScript Improvements
I am thinking of creating interconnected permissions system between an EntityFilterScript (EFS), a client and an additional external service. However for me to start working on it I need to lay the ground work into the server: I need to update the EntityEditFilters cpp so that the Script Engine used to process the EFS has access to connect to the Messaging Queue. As of the moment it is just a run in the mill QtEngine Additionaly Script Engine needs to have access to the 3d Math interfaces, and have access is all the interfaces needed to generate a HMAC-SHA256/512 signature and JSON processing. That would be the main change. JWT could be used to sign and authenticate claims between the two over the public Message queue. The Secret is shared between the client and the server, as both are assigned normally from the same place (EFS - AC) The Basic Vision is to allow for the creation of more nuanced EFS. An authorized (user or assignment) client that has a secret can then send commands to create some mutability to EntityFilter. Forexample this could be an Assignment client that monitors all entities "lastEditedBy", and connects them to users using an external service. This would relay this mapping to the EFS via the Messaging system. It would also send a list of override sessionIds (Admins) to the EFS that have access to everything. The EFS could then block any edits to objects that are not comming from a "related" sessionID, or Admin. If a user has access (admin or shared object) is editing someone elses object and has the permission to do so, the lastEditedBy field would not update.
Load More