Correction: The GNS resolver no longer synthesizes VPN records to IP addresses. You need to resolve the IP (A record) through the dns2gns DNS server or use gnunet-vpn and the information from the VPN record to do that.
BR On Thu, 2024-11-28 at 12:39 +0100, Martin Schanzenbach wrote: > Actually, there is a way you can simplify this feature: > > There is record type called "VPN". > > Its string format is: "<proto> <peerIDstring> <service>" > > The protocol is whatever protocol you want to use (e.g. git, http > etc). > The service string is some service descriptor you can also choose. > > Then you can setup a VPN service locally: > see > https://www.gnunet.org/en/use.html#vpn > and > https://docs.gnunet.org/latest/users/vpn.html > > > GNS can automatically synthesize an IP address and communication will > be established via cadet automatically. > > BR > Martin > > > On Thu, 2024-11-28 at 11:43 +0100, Martin Schanzenbach via > Mailinglist > for GNUnet developers wrote: > > Hello, > > > > thanks for tinkering with the GNS+Cadet stacks :) > > > > Here is what I got from my peer: > > > > " > > GIT_EXEC_PATH=$GIT_EXEC_PATH:$HOME/dev/git-remote-gnunet git clone > > gnunet://git.serv.amelia.gnunet.gns.alt/git-over-gnunet > > Cloning into 'git-over-gnunet'... > > Looking up git.serv.amelia.gnunet.gns.alt. > > Attempting to connect to peer > > DESNPFW7GF0NT3XZ9GJ5JPK18JF6DFZ9PD01QS31X8T93AN8X12G, on port > > `git.git- > > over-gnunet.git-upload-pack'. > > remote: Enumerating objects: 44, done. > > remote: Counting objects: 100% (44/44), done. > > remote: Compressing objects: 100% (40/40), done. > > remote: Total 44 (delta 18), reused 0 (delta 0), pack-reused 0 > > (from > > 0) > > Receiving objects: 100% (44/44), 15.22 KiB | 7.61 MiB/s, done. > > Resolving deltas: 100% (18/18), done. > > " > > > > As you can see, "git.serv.amelia.gnunet.gns.alt" which you > > registered > > via fcfs.gnunet.org also works. > > I am generally surprised that cadet works. Not so much that GNS > > works > > ;) > > > > Regarding your TODO and writing it as a "proper GNUnet service": I > > do > > not think that is actually necessary. Using CLI tools and chaining > > them > > like it is done right now is the UNIX-way of doing things, and > > there > > is > > nothing wrong with that. > > > > Good job > > Martin > > > > P.S: unlike using the remote-gnunet, I am unable to clone your repo > > using "traditional" means. The HTTPS URL cannot be cloned, the SSH > > link > > I cannot use for obvious reasons. > > > > On Wed, 2024-11-27 at 16:40 +0100, Amélia Coutard-Sander wrote: > > > Hello, > > > > > > In case anyone is interested, over the last few days, I have > > > coded- > > > up > > > a > > > prototype > > > (in bash) for a way to clone (and fetch, and pull) git repos over > > > GNUnet. > > > The git repo with the code is over at > > > https://git.ameliathe1st.gay/?p=git-over-gnunet.git, > > > if you want to check it out. > > > > > > Once you've obtained the source once, you can clone the repo > > > *using* > > > git > > > over > > > gnunet, at the address > > > gnunet://git.serv.000G0000V4BD1K10PRPGDKR916362AFZ12DBGA378EFRWPB > > > 0M > > > 54 > > > WHGX3YC/git-over-gnunet > > > . > > > See the README.txt for more details. > > > > > > It doesn't always work (and I haven't gotten pushing to work), > > > but > > > I > > > think that it > > > might be an issue with the gnunet-cadet cli (because it, for > > > example, > > > doesn't open > > > the connection if stdin reaches eof before the connection > > > attempt). > > > I'll try to investigate further. > > > > > > Thanks in advance for you interest and/or (more importantly) > > > criticism, > > > Have a nice day, > > > Amélia Coutard-Sander. > > > > > > > > > > >
signature.asc
Description: This is a digitally signed message part
