🚀 go-pugleaf

On 2024-07-18, rek2 hispagatos wrote:
>
> Hello anyone has any active/updated info on radio/satellite on gemini?

It'd be questionable at best (at least in the US), due to the integral
encryption.


--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

On 2024-07-18, Dan Purgert <dan@djph.net> wrote:
> On 2024-07-18, rek2 hispagatos wrote:
>>
>> Hello anyone has any active/updated info on radio/satellite on gemini?
>
> It'd be questionable at best (at least in the US), due to the integral
> encryption.
>

I do not think is questionable at all, we have rec.radio.* groups here
in usenet also there are in Matrix and all over http, so was just
wondering if there is hamradio capsules on gemini, if you mention
because of satellites, there are plenty of amateur and public
satellites people can connect to when they are over your area.


Happy Hacking
ReK2

>

On 2024-07-19, rek2 hispagatos wrote:
> On 2024-07-18, Dan Purgert <dan@djph.net> wrote:
>> On 2024-07-18, rek2 hispagatos wrote:
>>>
>>> Hello anyone has any active/updated info on radio/satellite on gemini?
>>
>> It'd be questionable at best (at least in the US), due to the integral
>> encryption.
>>
>
> I do not think is questionable at all, we have rec.radio.* groups here
> in usenet also there are in Matrix and all over http, so was just
> wondering if there is hamradio capsules on gemini, if you mention
> because of satellites, there are plenty of amateur and public
> satellites people can connect to when they are over your area.

I think we're talking about two different things then. I read your
initial  question as "Are there any gemini capsules accessible via ham
radio services?".

There is nothing stopping anyone from writing a capsule that covers ham
radio topics, and hosting it "on the internet".  A ham radio operator in
the US simply cannot host (or access) gemini over the ham radio bands,
due to the integral encryption of the protocol.  For other
jurisdictions, consult with your equivalent of the FCC.


--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

On 2024-07-19, rek2 hispagatos <rek2@hispagatos.org.invalid> wrote:
> On 2024-07-18, Dan Purgert <dan@djph.net> wrote:
>> On 2024-07-18, rek2 hispagatos wrote:
>>>
>>> Hello anyone has any active/updated info on radio/satellite on gemini?
>>
>> It'd be questionable at best (at least in the US), due to the integral
>> encryption.
>>
>
> I do not think is questionable at all, we have rec.radio.* groups here
> in usenet also there are in Matrix and all over http, so was just
> wondering if there is hamradio capsules on gemini, if you mention
> because of satellites, there are plenty of amateur and public
> satellites people can connect to when they are over your area.
>
>
> Happy Hacking
> ReK2
>
>>

Gopher would be allowed for sure.

Dan Purgert <dan@djph.net> wrote:
>
>
> On 2024-07-18, rek2 hispagatos wrote:
> >
> > Hello anyone has any active/updated info on radio/satellite on gemini?
>
> It'd be questionable at best (at least in the US), due to the integral
> encryption.

I dislike the mandatory encryption in TLS, and it would seem that I am not
the only one; I have read about some others who also disliked it. But,
fortunately there are other possibilities.

Although using Gemini with ham radio is inappropriate due to encryption,
you might be able to use unencrypted protocols such as:

- Gopher (although there is no virtual hosting; I don't know whether or not
that will be a problem for your use)

- HTTP (if used without TLS; unfortunately some programs try to insist on
using TLS even if you do not want to do, and there are other complexity)

- Spartan (which uses the same file format as Gemini, so you could use the
same files with both Gemini and Spartan)

- Scorpion (if used without TLS; the protocol specification I wrote says
that servers should allow unencrypted connections if possible, due to this
and for other reasons)

- NNTP (if without TLS; again there is no virtual hosting but this will be
less of a problem if the names of the newsgroups do not conflict)

(unless there are other prohibitions relating to such things)

(Maybe UUCP is also possible; I don't know much about that)

Probably, Spartan can be used since it is the same file format than Gemini
(actually there is one difference, but it is close enough).

Of course without TLS it means that client certificates cannot be used, but
for public files, that will not be a problem, anyways.

You can write about radio/satellite on a Gemini server though, and these
problems will not apply for a usual internet access, unless you should need
to access these files by the ham radio or otherwise if you cannot or are
not supposed to (or don't want to) use encryption, for any reason. You can
also write about Gemini protocol and file format in a service that is using
a different protocol that I had listed above, without encryption.

If you are concerned about if the file is correct, one possibility is that
you can use the cryptographic hash of the file when accessing it to check
that it is correct (e.g. the "hashed:" scheme that I had written about, or
you can just do it manually instead if you prefer). (I don't know if this
prohibition of the "encryption" is including cryptographic hashes, but it
is not significant to this since the hash does not need to be sent to the
server in order to use it.)

I live in Canada and I do not know what rules are difference in Canada
relating to ham radio, though. (If you live in other country, then you
might consider that too)

--
Don't laugh at the moon when it is day time in France.

On 2024-07-30, news@zzo38computer.org.invalid wrote:
> Dan Purgert <dan@djph.net> wrote:
>>
>>
>> On 2024-07-18, rek2 hispagatos wrote:
>> >
>> > Hello anyone has any active/updated info on radio/satellite on gemini?
>>
>> It'd be questionable at best (at least in the US), due to the integral
>> encryption.
>
> [...]
>
> If you are concerned about if the file is correct, one possibility is that
> you can use the cryptographic hash of the file when accessing it to check
> that it is correct (e.g. the "hashed:" scheme that I had written about, or
> you can just do it manually instead if you prefer). (I don't know if this
> prohibition of the "encryption" is including cryptographic hashes, but it
> is not significant to this since the hash does not need to be sent to the
> server in order to use it.)

The specific (US FCC) rule is that an amateur radio operator is
prohibited from transmitting a message in such a way that the intended
meaning is obscured.

So a checksum / optional file hash (digital signature, etc.) is fine by
the rule, since the "encoded data" is merely a way to validate a
previously sent plaintext message made it across the network as you
intended.  There's no "obscured meaning" if you've got a HTTP server
accessible via radio that includes a listing of "file:checksum" pairs,
providing that you indicate what the checksums are (e.g. MD5, CRC32,
etc.)

Likewise a new code for CW transmissions, general data transfer, etc. is
perfectly fine, PROVIDED THAT the method of encoding/decoding is public
knowledge before you start using it.  There are some caveats to what
constitutes "public knowledge", but I think they're to the effect of "a
provably dated article in your club's newsletter" (or post-dated mail,
etc.).


--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

--=-SVbsh0oAQ34K/6uQe2uB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> It'd be questionable at best (at least in the US), due to the integral
> encryption.

Isn't encryption in ham banned everywhere?
What about configuring daemon to use TLS only to sign communication, not 
encrypt it?
--=-SVbsh0oAQ34K/6uQe2uB
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE5vWZ813v29my1WijJ327yryXom8FAma94cEACgkQJ327yryX
om+tvA//aF9Q+l96J4BwyaF1ZI/zqIxsR/b3P6728Sa4q+2ucrqPAhz8ISagFNvW
ePp1XT7DeWmpQ6k3ypzeD9j0C7pry/oAyzT+gWyQb3Eg33spG+4hn0dic2uIZpdr
tQY60fCO74wz/hMbZAAKGKuWDI35Mft3h62qIpHgENgP0pFPJRWRwU8OBTfT8N2w
y7Mb3GicSzvRVyxEoJqEdVHJ8qnlL9+Mkp7d6R4zO83a9XQ+gN2EFrcDUbXlTCp2
H7+LjkMlEWd6BC7jXG9bZOfWrrDbQp3bbcNrboCiRcsPlwBXvklKdl7QbKCGE5u2
oZ4H/sy9dz/w+mWUYkrzb46/My8GYuYoAK86/bKXH62bfAhq9uyx5oCWvIZx5Cmj
qkW7wKtjZxtcrA70NOoroHE+eLcqttuOW27BsjTJfdS3lqELakwm5Kp7Q1j6/k5a
4V2pO+YSjTkIiUYdvRm2w8+0dkXVf1KLZdmSKB84qJpcOk3sHjBi7FkSkPWL2rbt
ufdtDCMVnZft4H1wx1J/XSiKJpLpjY2kQfhYgb9c+uR2C2hJ7+igwAlaQxN8uCWE
cM7KK9bLY+Y8HxeIk6qIRti/8npRN+zfR5BbLMZWSpyxbEe2mpVDa1+5Nf4EN5Pl
g1Iu+D3WHoYRWUUcyJf3ZIO93WtwQkmQeuuIXgtFXydCwwvVsIc=Sp/M
-----END PGP SIGNATURE-----

--=-SVbsh0oAQ34K/6uQe2uB--

On 2024-08-15, Emil Tomczyk wrote:
>> It'd be questionable at best (at least in the US), due to the integral
>> encryption.
>
> Isn't encryption in ham banned everywhere?

I don't know, and didn't want to speak for everyone ;)

> What about configuring daemon to use TLS only to sign communication,
> not encrypt it?

I believe signatures are okay, as their intent is not to "obscure
meaning" of a transmitted message.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

On Thu, 15 Aug 2024 11:08:49 -0000 (UTC), Emil Tomczyk wrote:
> Isn't encryption in ham banned everywhere?

At least for countries following ITU regulations.  In the 2024 Radio
Regulations publication Volume 1, Chapter VI, Article 25, Section I
the following is stated:

"Transmissions between amateur stations of different countries
shall not be encoded for the purpose of obscuring their meaning, except
for control signals exchanged between earth command stations and space
stations in the amateur-satellite service. (WRC-03)"

<http://handle.itu.int/11.1002/pub/8229633e-en>

In the USA this is called out in Title 47 of the Code of Federal Regulations
Part 97.113 (a)(4):

(a) No amateur station shall transmit:
(4) Music using a phone emission except as specifically provided elsewhere
in this section; communications intended to facilitate a criminal act;
*messages encoded for the purpose of obscuring their meaning, except as
otherwise provided herein*; obscene or indecent words or language; or
false or deceptive messages, signals or identification.

(emphasis mine)

--
"The avalanche has started, it is too late for the pebbles to vote."
  --Kosh