Gosling library

[Sammysupport]

Ricochet was a messenger over Tor that expired, after the TorChat Pilot-Model has also expired.

While OnionShare has also added a simple chat and uses a Tor-internal chat server, Ricochet refreshed under: https://www.ricochetrefresh.net/ https://github.com/blueprint-freespeech/ricochet-refresh steered by this project: https://www.blueprintforfreespeech.net/ It is a quite good simple messenger over Tor, but missing any encryption "state of the art" feature, other Secure Messengers have.

Besides chat over OnionShare, RicochetRefresh seems not to use an intermediate server inside Tor and is true p2p functionality by the Gosling library, which might be of interest:

https://github.com/blueprint-freespeech/gosling

To start the Tor.exe, a simple Gui-page is used.

A users key is defined as: ricochet:yznunqbkofbyspsjutxfbhsjs5avbja7fpwbdj75jw34epis7szyhoad

Please evaluate and test, if two Spot-On instances can use also the p2p connection of Tor respectrive the Gosling library, to connect without the need of a NAT Port Forwarding or a dedicated Echo-Server in the web.

Spot-On => Gosling => Tor => Internet => and way back.

Please evaluate futhermore, if two Ricochet-strings can build a tunnel, over which two Echo-Participants can chat

Spot-On => Ricochet => Gosling => Tor => Internet => and way back.

(honestly ricochet reports a loss of 40-45 % of messages in specific chat group environment, so that another layer (Echo to Ricochet on Gosling on Tor to internet) might be a layer too much and slow, but probably a direct connection over gosling to tor network might be faster and more reliable, if Gosling lib replaces tor.exe - is still a future question, then gosling would be a kind of vidalia as a lib).

Probably the onion route is not fast enough for the Echo and ties the volatile Echo, which is beyond cryptographic routing, in an insecure simple, not even cryptographic routing.

But, if a connection could be turned out without the need to set up a Listener as Echo server or to forward a port, there could be a magnet-link to a server respective serverless (hence "urn:neighbour") in this format, while "ts = tor server" refers to the name-key of ricochet:

magnet:?ts=yznunqbkofbyspsjutxfbhsjs5avbja7fpwbdj75jw34epis7szyhoad &xt=urn:neighbour

Alternatively the URN could be urn:private-tortunnel-credentials

[

in addition to the format of "private application local interface" tunnels ("Patch Points") of Spot-On:

magnet:?ct=aes256&ht=blake2b_512&ic=15000&s1=u7aBNWL4rAud4UjYMp4e7pQksVtfkVtpa6sH5O4pioM=&s2=4BmBD9vrvIL3n7JQW/iJro5MOPFGfPTkT74LapqxhRgSyLMBOSkJePR5zgvPwH0cOAb/86GEmO2fIC0rstj7Zw==&xt=urn:private-application-credentials

]

If "Tor Tunnels" are inverted "Echo Patch Points" and allow to get rid of the NAT and Server topic by establishing a true p2p connection without the need to forward NATted ports, this would create an instant connection to another Echo participant.

Thanks for an evaluation if the localhost binding (not a hidden onion adress binding to a hidden server) can extend and simplify the connection protocols of Spot-On.

(PS: While Gosling seems to be a library for Tor, Reticulum seems to be a p2p library for I2P, which also promises instant connections without NAT-problems: https://reticulum.network/manual/interfaces.html - see the specs).

[textbrowser]

Not integrating libraries. NTL and NTRU are abandon-ware.

[textbrowser]

You're persistently ignoring a basic idea: Spot-On prefers integration into existing communications. It does not desire absorption of libraries. It does not desire obtuse concepts that are difficult to create, maintain, understand. Tor is simple. We don't care how to works. That's the basis on Spot-On too. You connect to a place, share a bunch of data, and communicate. More is not better. Rust, JS, whatever. This is yet another convoluted concept which results in obsolescence. Matrix requires accounts and knowledge of their networks and libraries and implementation. Proxies do not.

[Sammysupport]

how could a button start tor.exe for windows (or tor on linux) and set the right localhost details to run it over tor?

[textbrowser]

You're asking the wrong question again.

[textbrowser]

And alluding to nonsense.

[Sammysupport]

A common word in our persistent persia is: "Better having a wedding planner one thousend and one night for Sheherazade than divorcing a donkey in a planned obsolescence". According to the tale the goose might know the mother in law?

[textbrowser]

[Sammysupport]

We got it ... - if Torbrowser runs, also Spot-On runs! :-).

[textbrowser]

Arguably easier to configure a proxy in Spot-On compared with Firefox. That is what you should be learning from this. You're saying: but Spot-On should know where Tor is. No, it should not. Tor does not have a universal place. You can have a Pi running Tor on a private network and expose the proxy to computers on that private network. So Spot-On or Firefox cannot know that. They could ping computers on ports but that's how you lose faith in a program. It does things without you.

[Sammysupport]

Did you get that it is not about running a Spot-Client over Tor to a Spot-Listener in the Web, "one-siding" works. How to tie a Spot-Listener to Tor, so that two Spot-clients connect to each other both behind Tor? SpotClient-Localhost-Tor-...-Tor-Localhost-ListenerofSpot | that might not work without an intermediate Tor-Server with an Onion-Adress to be entered in both Spot-Clients.

Tor should not be used for additional hops. It should help to get rid with port forwarding and NATs.

[textbrowser]

And again this is unrelated to this program.