feature/webring #18
Labels
No Milestone
3 Participants
Notifications
Total Time Spent: 1 week
Due Date
dozens
1 week
Dependencies
No dependencies set.
Reference: casa/pages#18
Loading…
Reference in New Issue
No description provided.
Delete Branch "feature/webring"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This adds a tildepals webring to our casapages!
LGTM!
@ -0,0 +1,32 @@
# webring
the benevolent tildepals basement heroes 43beans commonheath of casakhstan webring
commonhealth?
Edit: also webring/src/example.html#L16
good catch mio!
fixed!
comment from wsinatra:
Webring members can still link to the index page.
Gemini, gopher, and other nojs users will not benefit from the page redirect upon landing on the index page,
but they will still get to see the list of urls, and will be able to click on the next/previous url in the list to navigate to the next/previous webring site.
Additionally, any webring member can choose to "hardcode" the next and previous links on their site.
The webring should always be ordered sequentially by the ids of the member records in the recfile.
So if gemini site A with an id of 12 wanted to,
they could hard link to the URL of whatever site has an id of 13.
instead of linking to "https://...../index.html?name=gemsite&dir=next"
and relying on the index page to redirect the user.
It wasn't part of my original scope to accommodate nojs/gopher/gemini
but i feel like to a certain extent it might still "just work" through a bit of accidental graceful degradation:
even if the redirect doesn't work, you can still see all members, and you can still click through the list.
I guess I propose just adding a more concise note to that effect in the docs or on the index page.
Open to thoughts, comments, suggestions, recommendations!
Perhaps the index page could help with the static webring mode by having a HTML/Gophermap/Gemtext generator where you select yourself and it makes the hardcoded links. Surely more JavaScript is the solution for the no-JS case!
@ -0,0 +47,4 @@
<script>
const members = [
{
"id": false,
Now that's an interesting take on IDs 😛
that's going to be a problem actually,
i need to perform number math on that id value
(as opposed to the less reliable but arguably more popular feelings math)
@ -0,0 +31,4 @@
| rec2csv \
| csvjson \
| jq '. | {data: .}' \
| jq '{ data: [ .data[] | select(.feed != null) ] }' \
Couldn't those two
jq
calls be merged into a{ data: map(select(.feed != null)) }
, or maybe the filtering can be done inrecsel
directly?yes
this is a relic from when i had the rec->json transformation abstracted out into its own 'json' recipe.
to make the separate html and opml recipes,
i just copypasta the json recipe into them.
i think i always meant to go back
and do the filtering in recsel directly here.
@ -0,0 +7,4 @@
<ownerEmail>dozens@tilde.team</ownerEmail>
</head>
<body>
<outline text="tildepals webring" title="tildepals webring">
title
is only useful fortype="rss"
outlines, where it's supposed to be the<title>
of the RSS feed, so this can be omitted from other outlines@ -0,0 +9,4 @@
<body>
<outline text="tildepals webring" title="tildepals webring">
{{#data}}
<outline text="{{{name}}}" title="{{{title}}}" type="rss" xmlUrl="{{{feed}}}" />
This could include the website's URL as well using
htmlUrl
Idea from durrendal (wsinatra): a server-side redirection script.
Some background on the previous comment — this was based around the idea of a server-side script as an additional option with the following features:
prev/next: this would work from the readers' end similarly to the PR, but generated server-side, without js. Given a path to the page where the ring snippet would be embedded, a placeholder tag would be replaced with the generated snippet based on a customisable template (html, gopher, gemini, etc.)
list: lists all member sites. Like prev/next, this is could be extended for small net protocols e.g. by showing gopher readers a gopher file. This requires a host that supports the other protocols, or specifying different urls for other protocols, e.g. to another member site hosting the gopher/gemini version of the list. Not sure if casa pages ci can be configured to publish to other protocols (e.g. by copying files to the remote server's equivalent of
public_gopher
).random: this would randomly select a site from the data store and redirect readers to it. The sample code in the previous comment is for this part. This may be done dynamically, or a cronjob or similar can be set up to regenerate the snippet with a link set and thereby randomise the featured link at intervals.
New members may add their site here or in another git repo, and the data store is periodically pulled by the server script.
Another idea briefly suggested by wsinatra was optionally aggregating a few anonymous stats, such as number of site views and member referrer, i.e. which member site did visitors came from to arrive at another member site.
wsinatra is looking at a Lapis app that can also provide json api endpoints for others who want to pull updated data in a more commonly used format. If there is a spec, other implementations would be possible.
just chatted some with will, and we're both on board with just moving this whole thing over to a server-side script. i think he's willing to write some lapis and host it. he even has some mad ideas for proxying gopher/gemini content i think.
i'll leave this request open for a while for further comments and discussion, but i'm thinking of just closing this merge request and throwing my weight behind will's idea for implementation. it seems more inclusive for those using smol web and no-js browsers.
See durrendal's current progress on Project Katalogo:
https://gitlab.com/Durrendal/katalogo
Repo has moved to: https://codeberg.org/43beans/Katalogo
Let's move the discussion over to
https://codeberg.org/43beans/Katalogo
Closing this pull request!
Pull request closed