Add support for Introducer

changed milestone to %2024.10 LEAP VPN Release

assigned to @peanut2

For the first Poc, we want to use an obfs4 bridge. Therefore, we need a menshen instance behind a obfs4 bridge. There are also a lot of UI todos. I hope @jkito you can take care of it.

this might not be required, the idea is that the the obfs4 bridge will tunnel tcp+http traffic instead of openvpn traffic, so the existing obfs4 bridges can be used, but @sgk can confirm this. Or you mean something that can only be accessed via the obfs4 bridge and is not accessible directly (using firewall to only allow incoming from the obfs4 bridge ip and drop everything else)?

For the GUI part, just for the PoC i can add a text box somewhere with a button to input the URL but anything permanent needs to be first well thought out and designed in figma

Introducer must be stored in the config file

the bitmask-core has a config storage, and it already uses it to store the introducers there, it can also store more than one, in the desktop client i'd prefer to make use of that instead of augmenting the current storage code (https://0xacab.org/leap/bitmask-core/-/tree/main/pkg/storage)

what we'll need to store in the current config file is if an introducer should be used, so just a boolean for this should be enough

this might not be required, the idea is that the the obfs4 bridge will tunnel tcp+http traffic instead of openvpn traffic, so the existing obfs4 bridges can be used...

Did You mean "can't be used"? We need to test the introducer. So on the server side, we need an obf4 endpoint sitting in front of menshen.

For the GUI part, just for the PoC i can add a text box somewhere with a button to input the URL but anything permanent needs to be first well thought out and designed in figma

That's fine for me. We should add a switch that it's not showed as default. Maybe check if apiVersion in the provider config is 5?

bitmask-core has a config storage, and it already uses it to store the introducers there,...

We could use it that way, but then we have an additional config file, aside from the existing systray.json.

what we'll need to store in the current config file is if an introducer should be used, so just a boolean for this should be enough

Yep.

the bitmask-core has a config storage, and it already uses it to store the introducers there, it can also store more than one, in the desktop client i'd prefer to make use of that instead of augmenting the current storage code (https://0xacab.org/leap/bitmask-core/-/tree/main/pkg/storage)

I would actually prefer if we kept the storage outside of bitmask-core as long as we didn't write a proper storage layer that works well both on Desktop and Android. For example, on Android we don't store any data unencrypted anymore - that was part of the result of an security audit - and while it's questionable if in this concrete case introducers really need to be stored encrypted it would be nice if we had a thin interface that each client can implement to store the data however they want - may that be an file, a db or encrypted shared preferences in Android.

However - if that seems to be somewhat blocking the Desktop development - we can go ahead with storing data like it's currently done in bitmask-core, introduce these kind storage adapters later on and handle the current storage mechanism as the default adapter.

this might not be required, the idea is that the the obfs4 bridge will tunnel tcp+http traffic instead of openvpn traffic, so the existing obfs4 bridges can be used, but @sgk can confirm this.

I think, It needs to be an extra instance that doesn't point to a gateway.

Did You mean "can't be used"? We need to test the introducer. So on the server side, we need an obf4 endpoint sitting in front of menshen.

the current deployments in the demo instance already does this, i.e points to the nginx serving the api, so i thought this was not needed, but you are right.. obfs4 needs to be deployed in a different way for it to act as an introducer that is foward to the nginx instead of openvpn server

added 15m of time spent at 2024-08-21

added time estimate of 3h

I need to know where the introducer information is stored. I need to finalize the API in bitmask-core. I will change the logic in the desktop. Right now, I have a single API object (bitmask-core bootstrap.API). In the future I will create an API object every time I need it (e. g. to ask for Gateways). When I create a new API object, I can set the introducer.

In systray.json, there will be a flag UseIntroducer. For me it would be nice if we could save the introduce rinformation in systray.json. Then, from the desktop side code we could just do the following:

API = NewConfig(introducer="") with empty introducer when introducer is disabled in the preferences
API = NewConfig(introducer="obfs4://..) with an enabled introducer and the introducer is stored in systray.json

When we use the storage module/feature of bitmaks-core, then we need a new boolean flag in The config struct UseIntroducer.

TLDR: I would like to save the introducer url in systray.json.
Uddate: Also on Android we don't use the storage feature of bitmask-core, as there is no such thing as ~/.config...

I need to know where the introducer information is stored. I need to finalize the API in bitmask-core. I will change the logic in the desktop. Right now, I have a single API object (bitmask-core bootstrap.API). In the future I will create an API object every time I need it (e. g. to ask for Gateways). When I create a new API object, I can set the introducer.

everytime we have to create a new bootstrap.API using bootstrap.NewAPI() we need the Config struct which is created by bootstrap.NewConfig and we can easily set the Introducer like its currently being done for the other config field here: https://0xacab.org/leap/bitmask-vpn/-/blob/main/pkg/vpn/menshen/init.go?ref_type=heads#L81-L84

i don't see a need to change the current bitmask-core API, at least not for setting introducer, maybe i am missing something?

In systray.json, there will be a flag UseIntroducer. For me it would be nice if we could save the introduce rinformation in systray.json. Then, from the desktop side code we could just do the following:

API = NewConfig(introducer="") with empty introducer when introducer is disabled in the preferences

API = NewConfig(introducer="obfs4://..) with an enabled introducer and the introducer is stored in systray.json

When we use the storage module/feature of bitmaks-core, then we need a new boolean flag in The config struct UseIntroducer.

TLDR: I would like to save the introducer url in systray.json.
Uddate: Also on Android we don't use the storage feature of bitmask-core, as there is no such thing as ~/.config...

About where to store the information if a introducer should be used, i.e UseIntroducer this will be set from the GUI so this goes to the systray.json file (this file currently stores things that are set/unset from the GUI)

storing the Introducer URL (and name) also there would be limiting if we use the current flat structure (being able to store only one like you mentioned in the issue description). we have to modify the current config JSON structure to be able to store multiple introducers, we also need to store a name for the introducer to show in the GUI as showing the introducer URL wouldn't look nice

lastly, the advantage of using the config/storage from bitmask-core is that it removes the need to do JSON parsing, and it can be used to also cache the gateways and bridges as go structs (but this is for later, i think it currently already supports caching bridge information)

storing the Introducer URL (and name) also there would be limiting if we use the current flat structure (being able to store only one like you mentioned in the issue description). we have to modify the current config JSON structure to be able to store multiple introducers, we also need to store a name for the introducer to show in the GUI as showing the introducer URL wouldn't look nice

I don't understand. We only need to store a single introducer. Why can't we just use

{
	"UseIntroducer": true,
	"introducer": {
		"name": "does a name even make sense?",
		"cert": "bla",
		"host": "1.2.3.4",
		"port": "444e"
	}
}

in systray.json?

As cyberta said, the Storage layer of bitmask-core does not fit into the Android world.

Regarding the interface to change the Introducer:
Right now in the desktop, we have a single API object. Then have different calls on that like GetGateways. The Android layer currently initiates a new API object for every request to menshen (see https://0xacab.org/leap/bitmask-core/-/blob/main/pkg/mobile/bitmaskmobile.go?ref_type=heads).

We could change the introducer by modifing the config and creating bootstrap.NewAPI(bm.config) every time we have an API call to menshen. But I recently just recognized that during startup, we need to call api.DoLocationLookup() once (without VPN). Then the country code ist stored internally in the API object. Then later we can call api.GetAllGateways multiple times already knowing the country code.

If we have a single API object, then we need to add a setter function to change the introducer of the API object. That's my current plan.

I don't understand. We only need to store a single introducer. Why can't we just use

we can use that, but its not needed, and it limits us by forcing to store only one introducer information, the only one introducer limitation is artificial, nothing prevents us from storing more than one, and allowing the ability to users to be able to switch between introducers and choose whatever works for them at the moment.

also its not needed because bitmask-core automatically uses that storage layer, so even if you store the values in systray.json there will be a bolt db created in ~/.config/bitmask/bitmask.db

As cyberta said, the Storage layer of bitmask-core does not fit into the Android world.

the storage layer for android will always be different, but we are talking about using it in the desktop client. so even if you use systray.json it is already different from how android app is storing the config options

If we have a single API object, then we need to add a setter function to change the introducer of the API object. That's my current plan.

even with a setter that changes the value of Config.Introducer you'd need to call bootstrap.NewAPI again with the updated Config struct, as changing the value in the Config struct would not affect the previously created http Client which is using the old introducer information, see: https://0xacab.org/leap/bitmask-core/-/blob/main/pkg/bootstrap/init.go?ref_type=heads#L152

we can use that, but its not needed, and it limits us by forcing to store only one introducer information, the only one introducer limitation is artificial, nothing prevents us from storing more than one, and allowing the ability to users to be able to switch between introducers and choose whatever works for them at the moment.

That's true. I spoke with @cyberta about this and we agreed on this because it makes the UI much simpler.

also its not needed because bitmask-core automatically uses that storage layer, so even if you store the values in systray.json there will be a bolt db created in ~/.config/bitmask/bitmask.db

True but we could remove this feature. For me it's a bit odd to have two config files for such a simple application.

even with a setter that changes the value of Config.Introducer you'd need to call bootstrap.NewAPI again with the updated Config struct, as changing the value in the Config struct would not affect the previously created http Client

Yes, we not only have to change the Introducer, we also need to update the http client. But that's not a problem. https://0xacab.org/leap/bitmask-core/-/blob/main/pkg/bootstrap/init.go?ref_type=heads#L98

True but we could remove this feature. For me it's a bit odd to have two config files for such a simple application.

bitmask-core storage solution is more for persistent storage then config, so i see this as not two config solution but config and a storage solution, looking at the code and commits the repo, the way forward would be to a layer that stores the config in the correct way in android as well

Yes, we not only have to change the Introducer, we also need to update the http client. But that's not a problem.

then you have the same kind of API as it exists currently, no? what i am asking is how does the changed API for bitmask-core improve things or what it solves

then you have the same kind of API as it exists currently, no? what i am asking is how does the changed API for bitmask-core improve things or what it solves

The country code gets fetched once and is stored as a variable in the API object. When the user changes the introducer settings, we need to update the API object. So it needs to be possible to change the introducer/httpClient aterwards.

mentioned in issue bitmask-core#14 (closed)

added 30m of time spent at 2024-08-22

added 30m of time spent at 2024-08-26

mentioned in issue bitmask-core#21 (closed)

mentioned in merge request bitmask-core!23 (merged)

changed milestone to %2025.02 LEAP VPN Release

added 15m of time spent

To get basic introducer support via environment variable for testing, there is this MR: !265 (merged)
This issue depends on the provider agnostic desktop. I unassign the issue. @jkito feel free to assign yourself and change the milestone as you wish.

unassigned @peanut2

assigned to @jkito

changed the description

changed time estimate to 2h from 3h

done in !265 (merged)

closed

Add support for Introducer

Features we want to have:

People can add a introducer

GUI

Data

Designs

Child items 0

Activity