feature/webring #18

Closed
dozens wants to merge 6 commits from feature/webring into main
Owner

This adds a tildepals webring to our casapages!

This adds a tildepals webring to our casapages!
acdw was assigned by dozens 2023-10-30 20:24:28 +00:00
lucidiot was assigned by dozens 2023-10-30 20:24:28 +00:00
m455 was assigned by dozens 2023-10-30 20:24:28 +00:00
mio was assigned by dozens 2023-10-30 20:24:28 +00:00
dozens added 4 commits 2023-10-30 20:24:28 +00:00
dozens requested review from mio 2023-10-30 20:25:17 +00:00
dozens requested review from lucidiot 2023-10-30 20:25:17 +00:00
dozens requested review from acdw 2023-10-30 20:25:17 +00:00
dozens requested review from m455 2023-10-30 20:25:18 +00:00
dozens requested review from nihilazo 2023-10-30 20:25:18 +00:00
dozens started working 2023-10-30 20:25:32 +00:00
Author
Owner

LGTM!

LGTM!
mio reviewed 2023-10-30 20:44:27 +00:00
@ -0,0 +1,32 @@
# webring
the benevolent tildepals basement heroes 43beans commonheath of casakhstan webring
Owner

commonheath

commonhealth?

Edit: also webring/src/example.html#L16

>commonheath commonhealth? Edit: also [webring/src/example.html#L16](https://tildegit.org/casa/pages/src/commit/ffc1c77ad0851da7b1e4f9897ace260f00100d6f/webring/src/example.html#L16)
Author
Owner

good catch mio!
fixed!

good catch mio! fixed!
dozens marked this conversation as resolved
dozens added 1 commit 2023-10-30 21:20:12 +00:00
Author
Owner

comment from wsinatra:

15:25 <wsinatra> dozens: please consider how we can add gemini/gopher links to the ring (I don't have an account so can't just comment on the MR)
15:25 <wsinatra> want some brain power on that idea as mio's blog is only gemini now
15:26 <dozens> good point! i'll add a comment.
15:26 <dozens> i think that nojs and gemini/gopher sites could always link back to the index page.
15:26 <dozens> it just won't automatically redirect.
15:26 <dozens> but the user can still just manually click on the urls upon arriving at the index
15:27 <wsinatra> thank you! I can come contribute an etlua template too if it helps
15:27 <wsinatra> dunno if anyone else is using lapis
15:27 <wsinatra> but I'll have to do it anyways so might as well :)

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!

comment from wsinatra: ``` 15:25 <wsinatra> dozens: please consider how we can add gemini/gopher links to the ring (I don't have an account so can't just comment on the MR) 15:25 <wsinatra> want some brain power on that idea as mio's blog is only gemini now 15:26 <dozens> good point! i'll add a comment. 15:26 <dozens> i think that nojs and gemini/gopher sites could always link back to the index page. 15:26 <dozens> it just won't automatically redirect. 15:26 <dozens> but the user can still just manually click on the urls upon arriving at the index 15:27 <wsinatra> thank you! I can come contribute an etlua template too if it helps 15:27 <wsinatra> dunno if anyone else is using lapis 15:27 <wsinatra> but I'll have to do it anyways so might as well :) ``` 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!
lucidiot reviewed 2023-10-31 08:43:47 +00:00
lucidiot left a comment
Owner

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!

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,
Owner

Now that's an interesting take on IDs 😛

Now that's an interesting take on IDs 😛
Author
Owner

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)

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)
dozens marked this conversation as resolved
@ -0,0 +31,4 @@
| rec2csv \
| csvjson \
| jq '. | {data: .}' \
| jq '{ data: [ .data[] | select(.feed != null) ] }' \
Owner

Couldn't those two jq calls be merged into a { data: map(select(.feed != null)) }, or maybe the filtering can be done in recsel directly?

Couldn't those two `jq` calls be merged into a `{ data: map(select(.feed != null)) }`, or maybe the filtering can be done in `recsel` directly?
Author
Owner

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.

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.
dozens marked this conversation as resolved
@ -0,0 +7,4 @@
<ownerEmail>dozens@tilde.team</ownerEmail>
</head>
<body>
<outline text="tildepals webring" title="tildepals webring">
Owner

title is only useful for type="rss" outlines, where it's supposed to be the <title> of the RSS feed, so this can be omitted from other outlines

`title` is only useful for `type="rss"` outlines, where it's supposed to be the `<title>` of the RSS feed, so this can be omitted from other outlines
dozens marked this conversation as resolved
@ -0,0 +9,4 @@
<body>
<outline text="tildepals webring" title="tildepals webring">
{{#data}}
<outline text="{{{name}}}" title="{{{title}}}" type="rss" xmlUrl="{{{feed}}}" />
Owner

This could include the website's URL as well using htmlUrl

This could include the website's URL as well using `htmlUrl`
dozens marked this conversation as resolved
lucidiot added the due date 1970-01-01 2023-10-31 09:18:04 +00:00
dozens added 1 commit 2023-10-31 14:47:25 +00:00
ca665dbbf3 fixes a few comments from lucidiot
- adds `htmlUrl` to opml entry items
- removes `title` from opml entity
- removes superfluous jq call, moves query to recsel

**NOTE:** mustache apparently has a quirk where when iterating over a
list, it will interpret a 0 and a 1 as false and true unless/until there
is also a 2. at which point it will start interpreting the numbers as
numbers. this commit does NOT fix this. i just manually changed the
`false` to `0` in the generated html. this problem will fix itself once
we have at least 3 webring members.
Owner

Idea from durrendal (wsinatra): a server-side redirection script.

@durrendal    the web ring would just 301 redirect to the server and then it would render a random link and 301 redirect again?
@durrendal    I kind of like this idea, it's crazy, but would be really easy to do in lapis
@durrendal    return { redirect_to = self:build_url(casa.random) }
@durrendal    literally this in an app:match("index", "/", function(self)
@durrendal    so
@durrendal    app:match("index", "/", function(self)
@durrendal    return { redirect_to = self:build_url(casa.random) }
@durrendal    end
@durrendal    would be almost the entire contents of app.lua
@durrendal    and your db could be anything, csv, json, rec, sqlite. doesn't matter so long as casa.random function in casa.lua maps to some random selection that returns a valid url
Idea from durrendal (wsinatra): a server-side redirection script. ``` @durrendal the web ring would just 301 redirect to the server and then it would render a random link and 301 redirect again? @durrendal I kind of like this idea, it's crazy, but would be really easy to do in lapis @durrendal return { redirect_to = self:build_url(casa.random) } @durrendal literally this in an app:match("index", "/", function(self) @durrendal so @durrendal app:match("index", "/", function(self) @durrendal return { redirect_to = self:build_url(casa.random) } @durrendal end @durrendal would be almost the entire contents of app.lua @durrendal and your db could be anything, csv, json, rec, sqlite. doesn't matter so long as casa.random function in casa.lua maps to some random selection that returns a valid url ```
Owner

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.

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.
Author
Owner

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.

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.
Author
Owner

See durrendal's current progress on Project Katalogo:

https://gitlab.com/Durrendal/katalogo

See durrendal's current progress on Project Katalogo: https://gitlab.com/Durrendal/katalogo
Owner
Repo has moved to: https://codeberg.org/43beans/Katalogo
Author
Owner

Let's move the discussion over to
https://codeberg.org/43beans/Katalogo

Closing this pull request!

Let's move the discussion over to https://codeberg.org/43beans/Katalogo Closing this pull request!
dozens closed this pull request 2023-11-07 00:20:29 +00:00
dozens stopped working 2023-11-07 00:20:29 +00:00
1 week

Pull request closed

Sign in to join this conversation.
No description provided.