Hello list, I'm happy to announce the release of gwish v0.3!

gwish (pronounced [g◆iʃ]) is a command-line gwit client written in POSIX shell
as a one-piece script.  It strives to have absolute minimal dependencies which
you can find in a 10-year-old Unix box.  When possible, gwish tries to use the
example commands shown in the gwit specification, so as to serve as a
proof-of-concept, reference and inspiration for other implementations.

For more information, check out the project's homepage:
<https://git.sr.ht/~ivilata/gwish>

If you have any issues or comments, don't hesitate to contact me.  Thank you!

----

Ivan Vilata i Balaguer (2025-03-09 00:44:52 +0100) wrote:

> Hello list, I'm happy to announce the release of gwish v0.2!

I'm still trying to create a template for gwish announcements, and I realise
that I forgot to include the project's URL, sorry!

<https://git.sr.ht/~ivilata/gwish>

Cheers,

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

Hello list, I'm happy to announce the release of gwish v0.2!

gwish (pronounced [gu̯iʃ]) is a command-line gwit client written in POSIX shell
as a one-piece script.  It strives to have absolute minimal dependencies which
you can find in a 10-year-old GNU/Linux box.  When possible, gwish tries to
use the example commands shown in the gwit specification, so as to serve as a
proof-of-concept, reference and inspiration for other implementations.

If you have any issues or comments, don't hesitate to contact me.  Thank you!

----

This release adds support for site introductions, which are used for mirroring
sites, finding out new remotes and discovering new sites.  Site configuration

matograine (2025-03-08 10:16:51 +0100) wrote:

> Anyway, I have written tests for wet (still not for the rewrite algo) and
> fixed some bugs along the way.
> 
> I created a repo containing test sites, that will be useful for other
> developers. Naturally, there is a gwit site to present these ;-) :
> 
> => gwit://0x5b5a404b647a24c78f1a8efb2186a7ed03a08821#??https://framagit.org/matograine/gwit-tests.git
> 
> You may want to test gwish on these.

Hi Matograine, this is a very useful effort, thanks a lot!  I'll tell you if I
come up with additional interesting scenarios to add there.

Ivan Vilata i Balaguer (2025-02-13 12:39:49 +0100) wrote:

> Ivan Vilata i Balaguer (2025-01-27 20:07:22 +0100) wrote:
> 
> > matograine (2025-01-23 06:31:07 +0100) wrote:
> > 
> > > Le 22/01/2025 à 17:02, Ivan Vilata i Balaguer a écrit :
> > > >
> > > > => gwit://0x16C8A566BB88303C2513CF6328996D46E0440E85/blog/2024
> > > > /offlirsoch.gmi#existing-stuff??https://framagit.org/matograine
> > > > /gwitsite.git
> > > >
> > > > A client parsing that would get the fragment, cut it on the last `??`,
> > > > use the URL to its right as a remote, and leave the stuff to its left

Hi!  It's only been a few days since the announcement of Matograine's Wet, and
we already have a second gwit client!  Its name is [gwish][1], and it's a
one-piece shell script that strives to have absolute minimal dependencies
which you can find in a 10-year-old GNU/Linux or BSD box (namely the POSIX
shell & base utilities, plus Git and GnuPG).

[1]: https://git.sr.ht/~ivilata/gwish

gwish tries to use the example commands shown in the gwit specification both
to check their validity, and as a proof-of-concept, reference and inspiration
for other implementations.  This means that great effort was put in ensuring
that what's already there sticks to the spec as much as possible.

gwish still lacks much functionality in comparison with Wet, and it's not as

Ivan Vilata i Balaguer (2025-02-15 21:37:52 +0100) wrote:

> matograine (2025-02-15 08:56:40 +0100) wrote:
> 
> > I have been developping wet, a minimal gwit client, for a month or so.
> > I started it as a development target for libgwit, a python lib for Gwit.
> 
> And now for the surreal part…  I was just about to release another gwit client
> which I've been (very slowly) developing during the last months. […]
> 
> I'll do the formal introduction later in another thread (I don't want to
> hijack wet's introduction), but it'd be nice to coordinate to keep them
> compatible when useful (e.g. so that they can share mirrored sites).

matograine (2025-02-15 08:56:40 +0100) wrote:

> Hi !
> 
> # Introducing wet and libGwit
> 
> I have been developping wet, a minimal gwit client, for a month or so.
> I started it as a development target for libgwit, a python lib for Gwit.
> 
> => https://framagit.org/matograine/wet/
> => https://framagit.org/matograine/libgwit/
> 
> With wet, you can :
> - browse gwit sites

matograine (2025-01-23 06:31:07 +0100) wrote:

> Le 22/01/2025 à 17:02, Ivan Vilata i Balaguer a écrit :
> >
> > Instead, we may try to use a separator string that wouldn't be usually
> > found in URLs (nor fragments); we can count on the two extra characters
> > `/?` allowed in fragments, which will BTW be used with the usual
> > restrictions in the remote URL.  So with `/` we may use `///` as a
> > separator (`//` is obvously too frequent); with `?` we may use `??`.  >
> > Path components also allow `:` and `@`; I've seen chains of `:` in some
> > URLs, but never chains of `@`, so `@@` may be another option (I like that
> > it looks like a pair of eyes, or a "double at" for pointing at a
> > location).
> >

Hi, thanks for your observations!  You're right in your interpretation of the
spec; see inline for more details.

tom.ngr@zaclys.net (2025-01-15 17:36:17 +0100) wrote:

> I have a question about the expected behavior of URIs in context of browsing
> a site on a past commit.
> 
> Let's say we are on site 0xaaaa..., with HEAD of branch gwit_0xaaaaaaaa
> being commit 00000. I browse to a doc on a previous commit, let's say
> gwit://11111@self/index.gmi. Here I meet these links :
> 
> => gwit://0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
> => gwit://self/article.gmi