💾 Archived View for gemi.dev › gemini-mailing-list › 000467.gmi captured on 2024-05-26 at 16:00:21. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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.
Webrings would be better.
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.
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 ;)
> 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. :)
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>
> 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>
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>
>> 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.
> 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
---
Previous Thread: Supporting optional underscores for italics
Next Thread: Why not use the markdown way to deal with long lines?