Road to Throne

[parhelia512]

Leave your thoughts about Throne here.

[Mahdi-zarei]

Currently I am preparing the new icon/tray images. Then I need to rename some internal code stuff, preferably removing the word neko from the code base (I don't feel the name of the project should be used in the variables/classes etc). A couple more renaming regarding the file names, also a bit of code to handle the rename or relocation of files so that older config folder structures could be used with the new one and migration becomes easy. after that we could add the new features. feel free to help with these or do whatever you see fit.

[parhelia512]

I have created "1.0" milestone https://github.com/throneproj/nekoray/milestone/1.
You can add tasks/issues to milestone.

[parhelia512]

I will add legacy windows support to the main repository next week.

[parhelia512]

@Mahdi-zarei I refactored the code of core. Convert core server to a shared library.
go build -trimpath -tags "with_clash_api,with_gvisor,with_quic,with_wireguard,with_utls,with_ech,with_dhcp" -ldflags="-w -s" -o libcore.so(.dll/.dylib) -buildmode=c-shared
Source code is here. server.zip

[parhelia512]

Export symbols:
extern __declspec(dllexport) char* core_exit(char* text);
extern __declspec(dllexport) char* core_start(char* text);
extern __declspec(dllexport) char* core_stop(char* text);
extern __declspec(dllexport) char* core_check_config(char* text);
extern __declspec(dllexport) char* core_test(char* text);
extern __declspec(dllexport) char* core_stop_test(char* text);
extern __declspec(dllexport) char* core_query_url_test(char* text);
extern __declspec(dllexport) char* core_query_stats(char* text);
extern __declspec(dllexport) char* core_list_connections(char* text);
extern __declspec(dllexport) char* core_get_geoip_list(char* text);
extern __declspec(dllexport) char* core_get_geosite_list(char* text);
extern __declspec(dllexport) char* core_compile_geoip_to_srs(char* text);
extern __declspec(dllexport) char* core_compile_geosite_to_srs(char* text);
extern __declspec(dllexport) char* core_speed_test(char* text);
extern __declspec(dllexport) char* core_query_speed_test(char* text);
extern __declspec(dllexport) char* core_set_system_dns(char* text);

[parhelia512]

Useage:

QString Client::Start(const libcore::LoadConfigReq &request) {

    auto reply = spb::json::deserialize< libcore::ErrorResp >(std::string(core_start(spb::json::serialize< std::string >( request ).data())));
    return {reply.error.value().c_str()};
}

Here is a modified version of gRPC.cpp.
gRPC.zip

[parhelia512]

Windows build nekoray.zip.
Everything works fine except logs. This build still needs core. Because I haven't remove the code of core management and grpc.

[Mahdi-zarei]

I once thought about having the core as a lib, like Libbox that SFA uses, but there are several issues that make it hard. First thing is that we lose the ability to hard restart the core, as it no longer is a process you could simply kill or restart. Another is that on Linux you cannot set the system proxy when running as the root user, but you need root access for Tun mode. Third is actually there are lots of system Calls in the sing-box and I am kinda worried that not all of them will work properly when compiled to c code. So I guess it is best to keep the core a separate process to ensure things will remain safe and also have more control over it as a separate process.

[Mahdi-zarei]

There also seems to be a weird bug with the simple-protobuf library, #534, in this issue, from the second call onwards, the req.test_current is set to true, even though it was never assigned and should be the default, false. I will add this manually, but is there a way to have it default to the type's default value?

[Mahdi-zarei]

I fixed the issue with spb. There is also another thing that makes it not worth making the core a clib, and that is its crashes will cause the whole app to crash, we can of course add a recover to the main function but it really isn't a solution. So my final thought is that even though it is amazing to have a single binary to distribute, the amount of problems and complexities is simply too much and it is not a good idea to do it.

[parhelia512]

@Mahdi-zarei Thank you so much for your detailed explanation. I will stop further research on it.

[Mahdi-zarei]

Regarding simple protobuf, there are issues with default values as having fields set as required makes api calls cumbersome as we cant leave them empty, and having them set as optional will require a value_or all over the code. What are your thoughts about this? should we keep it and add the required code or revert back to google protobuf?

[parhelia512]

Setting a default value for a required field(like fd421d0) works or not?

[Mahdi-zarei]

It does work in the context of the value you read from it, but the problem is if you don't provide that field, the rpc will fail. Setting it as optional causes the code to break and we need to make significant changes.

[parhelia512]

https://github.com/throneproj/nekoray/tree/refs/heads/optional_field
https://github.com/throneproj/nekoray/actions/runs/16340534701

[parhelia512]

@Mahdi-zarei Please give read and write permissions to https://github.com/throneproj/throneproj.github.io.
https://github.com/throneproj/throneproj.github.io/settings/actions

[Mahdi-zarei]

You have to handle permissions in the workflow itself, the read and write option is grayed out and inaccessible for me too.

[parhelia512]

The Throne documentation website https://throneproj.github.io is online.
The contents still need to be improved https://github.com/throneproj/throneproj.github.io/tree/main/content.

[Mahdi-zarei]

Nice! We can eventually complete it

[Mahdi-zarei]

Do you think we should implement a kill switch? I think we should be able to do it, but i am not sure if it is worth the effort.

[parhelia512]

Kill switch will be tun-only featrue, right?

[Mahdi-zarei]

yes, basically we need to write another helper golang app which adds/removes some platform-specific firewall rules to block all connectivity. it cannot be in the core, since we need to block all internet if the core crashes too.

[parhelia512]

On windows, this feature is easily achieved by using winapi.
main.zip

[Mahdi-zarei]

I think linux shouldn't be hard either, some simple iptable rules that we could get from github or chatgpt.
I suspect macOS shouldn't be that hard too since we got root access, we just need to find the proper rules to apply.
I also think we could design the kill switch in a manner that does not need another binary:
mode 1: total kill switch: we simply apply the rules until user requests them to be removed, and will add a rule to allow access to the dest of vpn when starting a config.
mode 2: crash protection kill switch: we apply the kill switch when a Tun config is going to be started, and bring it down either when user requests or when the Config is stopped.
my only concern is about mode 1, since some configs hide behind CDNs, or their domain may resolve to lots of IPs, it may be a bit cumbersome to handle it properly. though i guess we can resolve such configs' domains first and pass an ip to sing-box so that there won't be this problem.

[parhelia512]

I think mode 2 is better.

[Mahdi-zarei]

I was thinking to have both, in the setting the uset chooses what he wants

[Mahdi-zarei]

@parhelia512
Could you please test the new builds on windows 10, etc? I have built them with openssl instead of the default Schannel and want to make sure it does not break anything.

[parhelia512]

It works well.

[netn992]

Please add support for the Amnezia WG protocol.

[Mahdi-zarei]

@parhelia512
I am planning for some major refactoring for the 1.0.9 release, and hopefully adding some minor support for Xray profiles in the next one, please try to make your changes in other branches since i may need to force push to the master sometimes and it may remove your commits unintentionally.

[parhelia512]

Roger that.

[parhelia512]

@Mahdi-zarei I have added support for the xhttp transport. A profile without extra scheme works well.
But lack of support for extra <-> sing-box config . I need your help.

1. extra sample from XHTTP: Beyond REALITY XTLS/Xray-core#4113 (comment).

    "extra": {
        "headers": {
            // "key": "value"
        },
        "xPaddingBytes": "100-1000",
        "noGRPCHeader": false, // stream-up/one, client only
        "noSSEHeader": false, // server only
        "scMaxEachPostBytes": 1000000, // packet-up only
        "scMinPostsIntervalMs": 30, // packet-up, client only
        "scMaxBufferedPosts": 30, // packet-up, server only
        "scStreamUpServerSecs": "20-80", // stream-up, server only
        "xmux": { // h2/h3 mainly, client only
            "maxConcurrency": "16-32",
            "maxConnections": 0,
            "cMaxReuseTimes": 0,
            "hMaxRequestTimes": "600-900",
            "hMaxReusableSecs": "1800-3000",
            "hKeepAlivePeriod": 0
        },
        "downloadSettings": { // client only
            "address": "", // another domain/IP
            "port": 443,
            "network": "xhttp", // must be "xhttp"
            "security": "tls", // or "reality"
            "tlsSettings": {
                // ...
            },
            "xhttpSettings": {
                "path": "/yourpath", // must be the same
                // ... other XHTTP params specific to download if needed
            },
            "sockopt": {} // will be replaced by upload's "sockopt" if the latter's "penetrate" is true
        }
    }

2. V2RayXHTTPOptions, V2RayXHTTPBaseOptions, V2RayXHTTPDownloadOptions struct.
   https://github.com/throneproj/sing-box/blob/b60cd958d0920c1426abe53127ce9fb20b73b23b/option/v2ray_transport.go#L112

[Mahdi-zarei]

I actually were planning to add it like this:
we add xray core to core, we support outbounds from Xray like this:
sing-box with mixed or Tun inbound and with a socks outbound to Xray core.
Xray core with a socks inbound and the real outbound.
With this design the complexity of integrating lots of things together would be gone.
adding xray protocols to sing-box will be a pain since sing-box may refactor lots of things and then we have to port our implementation which can be hard.
Since Xray will be embedded into the Core, we just have to start 2 cores to achieve the desired effect, and all DNS and routing stuff can still be done using the sing-box part, and only use Xray as the outbound which reduces the complexity of using it.
What do you think about this design?
my main reason for refactoring lots of things is also to pave the path for adding features like this so that the code won't become unmaintainable.

[Mahdi-zarei]

I'm going to start working on this soon. IMO it is better to have Xray included instead of re implementing it in sing-box, as it has lots of features and they change a lot, this way we could both adapt and extend our Xray features easily.

[parhelia512]

Okay, xhttp branch will not be merged to dev branch. But I think we should release the new version 1.0.9 soon and contain this patch. It provides support for xhttp before the new fusion core complete.

[Mahdi-zarei]

I agree. We could release it for the time being, until we develop a more feature-rich one. Just wait for me to add some UI for the new sing-box fields I have added (dial fields, tls fields etc). Then we can release 1.0.9

[Mahdi-zarei]

I am suspecting the nekobox fork guy is using his multiple accounts to spread non sense about this project to gain more users for his own. I mean, some accounts whose activities are like 2 issues in the entire span of the account are suddenly criticizing Throne and spreading that our project has security or performance issues and all advertise that the nekobox one is just great. Be mindful about these guys and block these accounts at once.

[Mahdi-zarei]

I have limited interactions with the project for users with new accounts, this should help keep mr.wants-donations out.

[parhelia512]

I think we should block that guy's accounts at the same time.
Following this step https://docs.github.com/en/communities/maintaining-your-safety-on-github/blocking-a-user-from-your-organization#blocking-a-user-in-the-organization-settings.
Blocking huakim, qr243vbi and bunzuhbu.

[Mahdi-zarei]

I already have blocked all the accounts he has used so far, and limited interactions so he cant use new ones.

[parhelia512]

@Mahdi-zarei new qr243vbi's subaccount hunbij.

[Mahdi-zarei]

blocked directly

[Mahdi-zarei]

I believe the refactorings are mostly done for now. I have migrated beans to modular outbounds, so that it will be easier to add new fields/outbound types. We can now continue adding more features.

[parhelia512]

Hurray for you!

[Mahdi-zarei]

I pushed my changes. Let's test them internally a little bit, then please inform me whenever you rebased the xhttp branch so that i can release 1.0.9. I want to include some information about the amount of changes we have made and that things might break in the release info, so preferably let me do the release.

[parhelia512]

Okay. There are some issues in wireguard outbound. I should fix them first.

[parhelia512]

@Mahdi-zarei I'm not familiar with wireguard. Will you please look into these?
Test link:
wg://162.159.192.1:500?private_key=OPH5uZZlwj6BMjeS32sA3AEj0tC+aEQ5M3KFq0UvXE4%3D&peer_public_key=bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo%3D&pre_shared_key=&reserved=208-194-173&persistent_keepalive=0&mtu=1280&use_system_interface=false&local_address=172.16.0.2/32-2606:4700:110:8287:1e16:d0aa:bcea:c240/128&workers=0&enable_amnezia=true&junk_packet_count=4&junk_packet_min_size=40&junk_packet_max_size=70&init_packet_junk_size=0&response_packet_junk_size=0&init_packet_magic_header=1&response_packet_magic_header=2&underload_packet_magic_header=3&transport_packet_magic_header=4#WARP

warp-108-imp.json is Throne 1.0.8 parsing from the test link.
warp-109-imp.json is Throne 1.0.9 parsing from the test link.
warp-109-mig.json is Throne 1.0.9 migration from warp-108-imp.json.

[Mahdi-zarei]

Yes i will work on it

[Mahdi-zarei]

Should be fixed in 936774c

[parhelia512]

It fixed! All the changes apply to xhttp branch. You can release v1.0.9.

[Mahdi-zarei]

I guess we need to rollback Qt's version, seems buggy.
#938

[parhelia512]

windows11 style is buggy. I think we just need remove windows11 from theme list.

[Mahdi-zarei]

I dont know, windows11 theme seems to be popular...

[Mahdi-zarei]

I feel like #947 could also be caused by Qt.

[parhelia512]

I have requested issue reporter to check if the issue can be reproduced on windowslegacy64 version.

[Mahdi-zarei]

I feel like it is better to use openssl for windows again. #966 this is caused by Throne trying to use TLS v1.3, openssl handles it, but it seems windows' own TLS backend does not support it on older platforms.

[parhelia512]

You are right, this is an issue with Qt's schannel TLS backend.

[Mahdi-zarei]

I will return openssl again then, its straightforward and more reliable

[parhelia512]

The old clash parser is difficult to maintain.
Please check https://github.com/throneproj/Throne/tree/clashparser. I'm using https://github.com/xmdhs/clash2singbox to convert clash config to sing-box config in this branch.

[Mahdi-zarei]

It is actually much better than our current code base, much less complexity. I don't have any clash configs to test it, so I can't tell if it worked or not, but code-wise, It looks great.

[Mahdi-zarei]

Do you know any public subscription that has XHTTP vless configs? I need some valid xray vless configs to test the new Xray implementation.

[parhelia512]

https://raw.githubusercontent.com/barry-far/V2ray-Config/refs/heads/main/Sub11.txt

[Mahdi-zarei]

The Xray implementation is mostly complete, things seem to work as expected. Please give it a try to see if there are any bugs.
https://github.com/throneproj/Throne/actions/runs/20421491961
Let's release a beta for wider tests later, but i still want to add some stuff before we release the 1.1.0 version.

[parhelia512]

Great! Everything is working normally.
Furthermore, I think we should release 1.1.0 beta1 and 1.0.13 at the same time.

[Mahdi-zarei]

I agree, once you release 1.0.13 i will release the 1.1.0 beta version, since we can't release them at the same time its best for the beta one to come after the stable one.

[parhelia512]

@Mahdi-zarei Some users report high memory usage after we migrating to new outbound-based proxy entity.
I did some tests with this subscription on Windows. Here are the results.

Version	Memory [MiB]	Lines	Relative memory usage
1.0.8	845.7	53636	100.00%
1.0.9	1917.7	53636	226.76%
1.0.13	2212.5	62330	261.62%
1.1.0-beta.1	2043.3	62330	241.61%

[Mahdi-zarei]

Seems to be an issue. Once i finish the work on crash dumps i will work on it, will need to get a heap profile to see if we need to optimize or if we are having some memory leak.

[Mahdi-zarei]

It seems the issue is that since our new data model has all the fields, it simply uses more ram. I think we should move to sqlite for our data storage, this way we do not need to load everything into ram. We also need to refactor the proxy list to use custom qt models so that the app won't lag on tab switches. This can take quite a long time since it is a fundamental change on how we manage every part of the app...