Geminisphere

1. text (a) sdfeu.org (text (a) sdfeu.org)

If clients would send referers, servers could collect (cache) and 
present those to clients asking for links _to_ the current page 
("backlinks" in wiki parlance), thus creating an interconnected gemini 
sphere.

Although not simple, I would enjoy bi-directional linking in Gemini.

Link to individual message.

2. Drew DeVault (sir (a) cmpwn.com)

Webrings would be better.

Link to individual message.

3. Luke Emmet (luke.emmet (a) gmail.com)

GUS already holds the back link graph and you can query it.

Luke

> On 13 Nov 2020, at 13:42, Drew DeVault <sir at cmpwn.com> wrote:
> 
> Webrings would be better.

Link to individual message.

4. text (a) sdfeu.org (text (a) sdfeu.org)

Webrings form a nice gemini sphere, too. True.

As I understand backlinks, they are more fine-grained, operating on page 
level.

Gemini Universal Search (GUS) seems like a great central index, thanks!

Clients be like: list the 3 pages known to link here ;)

Link to individual message.

5. Unicorn (unicorn (a) disroot.org)

> If clients would send referers, servers could collect [...]

If a client sends a referer, it is sharing information about the
user's browsing behaviour with a party that does not technically need
to know this information. I personally always felt like this is one of
the web's aspects that have more privacy downsides than uses, and as a
consequence, probably shouldn't be part of a protocol that "takes
privacy seriously".

In practice it's more of a "nice to have" feature for analytics, which
I think goes against the goal of Gemini of keeping things limited to
what's necessary to achieve its purpose, both for complexity's and
privacy's sake. :)

Link to individual message.

6. John Cowan (cowan (a) ccil.org)

On Fri, Nov 13, 2020 at 8:41 AM <text at sdfeu.org> wrote:


> If clients would send referers, servers could collect (cache) and
> present those to clients asking for links _to_ the current page
> ("backlinks" in wiki parlance), thus creating an interconnected gemini
> sphere.
>

A more Gemini-style approach would be to have the client keep this
information and add backlinks to the top or bottom of a text/gemini page
when it displays one.  That would give each page three kinds of links: a
backlink, a forward link (one that the user has followed already), and a
blue-sky link (one that the user has never followed).


John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Not to perambulate the corridors during the hours of repose
in the boots of ascension.       --Sign in Austrian ski-resort hotel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201113/4b43
1e1a/attachment.htm>

Link to individual message.

7. Alex // nytpu (alex (a) nytpu.com)

> If clients would send referers, servers could collect (cache) and
> present those to clients asking for links _to_ the current page
> ("backlinks" in wiki parlance), thus creating an interconnected
> gemini sphere.
I'm gonna call a no on one of the worst parts of http. While we're at it
lets add cookies so servers can preserve state across sessions, which is
very useful functionality and definitely not something that already is
possible to do without substantial privacy invasions. It's funny
because http actually had client certificates first too (TLS RFC dated
August 2008) and then decided that cookies were definitely needed
(Cookies RFC dated April 2011).

> A more Gemini-style approach would be to have the client keep this
> information and add backlinks to the top or bottom of a text/gemini
> page when it displays one. That would give each page three kinds of
> links: a backlink, a forward link (one that the user has followed
> already), and a blue-sky link (one that the user has never followed).
This is an excellent idea, and you don't even need to extend the spec
for this.

I feel the need to reiterate this again: there are lots of creative
things clients (and servers) can do, that don't require *any* changes to
the spec. Caching? Done. Backlinks? Of course! Even if you can't code
I'm sure some client authors would welcome nifty and creative
suggestions like this.

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201114/0fba
99c5/attachment.sig>

Link to individual message.

8. John Cowan (cowan (a) ccil.org)

On Sat, Nov 14, 2020 at 11:35 AM Alex // nytpu <alex at nytpu.com> wrote:


> It's funny
> because http actually had client certificates first too (TLS RFC dated
> August 2008) and then decided that cookies were definitely needed
> (Cookies RFC dated April 2011).
>

Standardization in the HTTP/HTML world has until very recently been a
matter of trying to catch up with what the browser authors are doing.  Now
the standardizers (the WhatWG) *are* the browser authors.

> This is an excellent idea, and you don't even need to extend the spec
> for this.
>

Thank you.  It's something I've been thinking about since Gopher days, but
Gemini makes it much easier.  Another addition is for a client to add a
link to a page that you jumped away from by manually entering an URL that
points to the page you went to (this would be a forward link).

> Caching? Done. Backlinks? Of course!


There's another idea that goes with the above; have an "itinerary server"
that has access to a specific user's backlinks and cache.  That way you can
publish your personal view of Geminispace, with the pages as they were when
you saw them and your whole path traceable by whoever you give access to
the server.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Schlingt dreifach einen Kreis vom dies!
Schliesst euer Aug vor heiliger Schau,
Denn er genoss vom Honig-Tau,
Und trank die Milch vom Paradies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201114/5c19
6ea7/attachment.htm>

Link to individual message.

9. text (a) sdfeu.org (text (a) sdfeu.org)

>> If clients would send referers, servers could collect [...]
> 
> [...] sharing information about the user's browsing behaviour with a 
> party that does not technically need to know this information [...] 
> shouldn't be part of a protocol that "takes privacy seriously".

Thanks, privacy and simplicity are very good arguments against 
collecting referers which I fabulated to be useful for establishing 
(back-)links to external pages that cite the currently viewed page.

Getting the impression "backlink" got interpreted differently in other 
comments of this thread, a quote from 
https://en.wikipedia.org/wiki/Backlink#Wikis:
> Backlinks are offered in Wikis, but usually only within the bounds of 
> the Wiki itself and enabled by the database backend. MediaWiki, 
> specifically offers the "What links here" tool, some older Wikis, 
> especially the first WikiWikiWeb, had the backlink functionality 
> exposed in the page title.

Also https://en.wikipedia.org/wiki/Blogosphere:
> The blogosphere is made up of all blogs and their interconnections.

Link to individual message.

10. Petite Abeille (petite.abeille (a) gmail.com)



> On Nov 15, 2020, at 17:08, text at sdfeu.org wrote:
> 
> Also https://en.wikipedia.org/wiki/Blogosphere:
>> The blogosphere is made up of all blogs and their interconnections.

Alternatively:

https://www.eod.com/devil/archive/blogosphere.html

Link to individual message.

---

Previous Thread: Supporting optional underscores for italics

Next Thread: Why not use the markdown way to deal with long lines?