Ability to change domain server ports
Having the ability to change the domain server ports would make it possible to natively run multiple domains on one machine. HIFI_DOMAIN_SERVER_HTTP_PORT=40100 HIFI_DOMAIN_SERVER_HTTPS_PORT=40101 HIFI_DOMAIN_SERVER_PORT=40102 <- overwrites the setting on launch HIFI_DOMAIN_SERVER_DTLS_PORT=40103 ...or arguments passed to program This would be so amazing! The assignment client already has -a and --server-port, but I cant run two domain servers at the same time on the same machine. --- This would also make deploying servers with Docker actually work. There's a terrible bug where incoming UDP traffic cant be received properly within a Docker network (google: docker UDP packet loss). Therefore I want to run my containers on the host using --net=host, but then I can't access each domain server's panel because I need to change those ports. If this get's fixed, our network of domains for everyone can run 100% stable. We want to give all the users places to spend time with each other and never have connectivity issues. It would be a step towards making it easier to host multiple domains. Edit: Here's a thing https://hub.docker.com/r/makitsune/hifi https://github.com/makitsune/docker-hifi-domain-server
Now that openXR 1.0 specification has been released, it will be a good idea to support it, it will allow support for all hmds without the need to support each one of them individually. https://en.wikipedia.org/wiki/OpenXR
Bring back the built-in Script Editor...
Earlier versions of Interface.exe included a built-in script editor that enabled you to: * Create, load, and work on simple Client scripts without having to leave Interface. * Focus on, edit, and restart one script without fumbling through Running Scripts... or having to Reload all content. * See relevant console.* and print log messages for the focused script in a dedicated console panel. * Interactively try one-liners and inspect/modify global variables live while the focused script is running. A few years ago this feature was removed by HiFi for apparent reason of being too "Desktop only." It was so useful to me, however, that I have maintained a working version as part of my local builds. There has been no great way to share this with others because it requires forking, patching, and compiling your own Interface.exe from source. I propose to package this up and contribute it instead as an optional and externally-maintained application extension under the Modkit framework. DEPENDS ON MODKIT
Refactor edit.js and related building code so community can improve build tools
I don't know if any plans to overhaul or build up the build tools already exist, but it seems like the open source community would be in a good position to develop it's own sandbox building tools, and a good way to start in that would be to make the existing code easier to read, and extract an API from it where new tools can be built with little effort.
Make the Create app work nicely with inspect.js and derivatives
When using the inspect.js script with the Create app active you are likely to unexpectedly duplicate entities. This is because the Create app re-uses the Alt key to duplicate entities. Option A: Change the Create app to use Ctrl+mouse-down to duplicate entities (instead of Alt+mouse-down), and not do anything for Alt+mouse-down Option B: Change the Create app to use Shift+mouse-down to duplicate entities (instead of Alt+mouse-down), and the Ctrl key to toggle the display the “railroad” axes (instead of the Shift key), and not do anything for Alt+mouse-down. Option C: Add a menu option to the Create app’s menu items, “Duplicate entities with Ctrl instead of Alt”, and make inspect.js also read the menu setting and use the key that Create isn’t using. (I.e., toggle between current behaviour and option A.) Background The inspect.js script uses the Alt key plus Ctrl and Shift combinations to orbit and pan the camera about any entity or avatar – the same control scheme as Second Life. (This control scheme is likely to be second nature to people who have come from Second Life.) - Alt + mouse up/down: zooms in / out. - Alt + mouse left/right: orbits left / right. - Alt + Ctrl + mouse up/down/left/right: orbits over / under / left / right. - Alt + Ctrl + Shift + mouse up/down/left/right: pans down / up / right / left. Unfortunately, the Create app uses the Alt key to duplicate entities. While the “official” inspect.js isn’t so useful for positioning the camera while using the Create app because the view snaps back to first person when the Alt key is released, 3rd party versions of inspect.js leave the camera where it is which is much more convenient for editing. (In the 3rd party versions, to snap back to first person, the user can press Esc or move their avatar.) Which raises another option to perhaps do in addition to one of the above … Option D: Update inspect.js with some of the improvements that 3rd parties have made to the script. In particular, the Fox Essentials (Cutelab) version has collected together various improvements from a number of people, including the CtrlAltStudio improvements.
Integrate Carbon or similar payment gateway
One of the most critical issues with High Fidelity as a platform right now is that of friction. Average users aren't going to want to do the multi-level abstraction of buying Ethereum, then buying the stablecoin (in a bank session), and then actually purchasing their content. Critical to reducing this friction is a secure payment integration that will allow users to add money into the economy. I propose using a third party payment processor; significant research would be required to determine the best option. https://www.carbon.money/ is an interesting possibility, as it is specifically designed for conversion between credit cards/apple pay/etc and stablecoins or other crypto. The direct conversion to stablecoin also avoids significant tax implications of dealing with crypto like Ethereum.
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 | … ]
A visual cue to indicate public or private proceedings
It is unclear domain to domain if recording of going’s on has been consensual. Some kind of menu colour change could be used to indicate this. Whilst this wouldn’t prevent none consensual recording it would indicate where it has taken place.
(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.
I'd like to open a discussion on how to implement inventory. After surveying a few other virtual worlds, the concept of user-owned inventory seems to be missing. Also, the marketplace seems to be vestigial in HF at the moment (please correct me if I'm wrong), and I think the concept of owning digital content should not be overlooked. After some thought, I really still like the blockchain certificate concept from HF, but it would be nice if it could be pinned to something already in existence and in use. I would really like to see people able to buy from each other 1-to-1 and shop for and purchase online the way we purchase anything else, via paypal or some other merchant checkout. For the concept of people running their own servers, it probably isn't too far a stretch to expect people to carry their own inventory as well. How to allow this and maintain creator protection is something I'd like to talk about more and put some ideas on the table.