From Paul Wise to ~akselmo/Aks_Dev-MailingList
On Sun, 2023-06-04 at 19:06 +0300, Akseli Lahtinen wrote: > I found an alias command I could use to redirect the old urls to new ones. I see that it is a HTML based redirect instead of HTTP based. It isn't the best option but it will still work for archiving. > Can you check if it's working for you? Is it possible for you to provide a list of all the redirect pages, so that I can get those archived too? --
From Paul Wise to ~akselmo/Aks_Dev-MailingList
Akseli Lahtinen wrote: > Note: Old links to my site do not work anymore, due to change in the URL layout!! Would it be possible to add an index page containing links to all of the old URLs, plus add redirects from the old URLs to the new ones? Then ArchiveTeam can save all the redirects to new URLs to archive.org using ArchiveBot. Afterwards you can remove the index and redirects. https://wiki.archiveteam.org/index.php/ArchiveBot -- bye,
From Paul Wise to ~sircmpwn/sr.ht-dev
Makes it easier to find repos in the history of browsers that save titles. Potentially makes web search engine results more useful. --- hgsrht/templates/repo.html | 2 +- hgsrht/templates/summary.html | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/hgsrht/templates/repo.html b/hgsrht/templates/repo.html index 91c0229..c96fdb5 100644 --- a/hgsrht/templates/repo.html +++ b/hgsrht/templates/repo.html @@ -7,7 +7,7 @@ /!\ Mercurial 4.8 or newer is required. /!\ [message trimmed]
From Paul Wise to ~sircmpwn/sr.ht-dev
Makes it easier to find repos in the history of browsers that save titles. Potentially makes web search engine results more useful. --- gitsrht/templates/summary.html | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/gitsrht/templates/summary.html b/gitsrht/templates/summary.html index 869e368..bea2b54 100644 --- a/gitsrht/templates/summary.html +++ b/gitsrht/templates/summary.html @@ -1,7 +1,13 @@ {% extends "repo.html" %} {% import "utils.html" as utils with context %} [message trimmed]
From Paul Wise to ~cadence/bibliogram-devel
--- docs/Instances.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Instances.md b/docs/Instances.md index 0efc568..d009969 100644 --- a/docs/Instances.md +++ b/docs/Instances.md @@ -19,7 +19,7 @@ |https://bibliogram.pussthecat.org |🇩🇪 DE |✅ |✅ | | |https://bibliogram.1d4.us |🇨🇦 CA |✅ |✅ | | |https://insta.trom.tf |🇩🇪 DE |✅ | | | |https://bibliogram.hamster.dance |🇺🇸 US | | | | |https://bibliogram.hamster.dance |🇺🇸 US |✅ | | | [message trimmed]
From Paul Wise to ~sircmpwn/public-inbox
A couple of resources related to making money in FOSS: https://www.fossjobs.net/ https://github.com/fossjobs/fossjobs/wiki/Resources -- bye, pabs https://bonedaddy.net/pabs3/
From Paul Wise to ~sircmpwn/public-inbox
On Fri, 2020-06-12 at 21:24 -0400, Drew DeVault wrote: > The issues you mention don't affect the use-case I described, though. > The end-user would never be expected to handle the certificates, just > the service provider and the API client. Sure, I wanted to answer the general question of why they are an unused technology that thus is likely to bitrot and disappear. -- bye, pabs https://bonedaddy.net/pabs3/
From Paul Wise to ~sircmpwn/public-inbox
The issue with client-side certificates is entirely the fault of the browser vendors. The user interface for browser-native authentication methods in general is terrible (modal dialogs in Firefox). The user interface for expired client certs is exactly the same as for expired server certs, so there is a large user support burden just from yearly expiring client certs. The W3C and browser vendors also dropped support for the <keygen> tag so users have to drop to the command-line to create new keys, which basically no-one except technical users can do. Also, since it removes control of the authentication flow from web designers, web developers and puts it in the hands of the web server and sysadmin, it is probably unpopular with the folks who control websites since users get subjected to substandard login UX. The new WebAuthn standard (that only works with JS IIRC) replaces client certs for the browser vendors, so it is likely client certs will be
From Paul Wise to ~sircmpwn/sr.ht-dev
A shorter email signature wastes less space in email viewers. --- todosrht/emails/new_ticket | 5 +---- todosrht/emails/ticket_assigned | 5 +---- todosrht/emails/ticket_comment | 5 +---- todosrht/emails/ticket_mention | 5 +---- 4 files changed, 4 insertions(+), 16 deletions(-) diff --git a/todosrht/emails/new_ticket b/todosrht/emails/new_ticket index a9de111..d029b86 100644 --- a/todosrht/emails/new_ticket +++ b/todosrht/emails/new_ticket @@ -2,7 +2,4 @@ {{ticket.description}} [message trimmed]
From Paul Wise to ~sircmpwn/sr.ht-dev
This is the separator specified in RFC 3676 item 4.3. See-also: https://www.ietf.org/rfc/rfc3676.txt See-also: https://en.wikipedia.org/wiki/Signature_block --- todosrht/emails/new_ticket | 2 +- todosrht/emails/ticket_assigned | 2 +- todosrht/emails/ticket_comment | 2 +- todosrht/emails/ticket_mention | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/todosrht/emails/new_ticket b/todosrht/emails/new_ticket index 88720b1..a9de111 100644 --- a/todosrht/emails/new_ticket [message trimmed]