@alcinnz

this really aligns with some of my interests

the only gripe I have is.... if you're publishing a "website" over git you don't really need any special new protocol for internal links.
you can just use relative links like "./README.md", relative to the file you're currently in.

which does get a little complicated for sites where things can move around or where there are a lot of levels of organisation

but for, say, a rendered folder with one flat directory it's not so bad

@alcinnz

for I ended up inventing a uri scheme based on the nickname of the bop stem ("blog") and Created Date:

issues.bop/1608963724

Created Dates are ideally unique per "blog" because it's hard for a human to create any two entries at the same unix second.
the problem is I also use them to sort entries in a file manager, so occasionally they change; I'm aiming to fix this with something like, almost every move aliases the 'real' created date to the pretty one.

Follow

@alcinnz

what this hinges on is each "blog" would have a set of definitions of where each nickname "really" is,
so one could easily update that definition instead of having to update the "host" in every single link like The Web currently makes you do

I got this idea from one of those "petnames" articles I think you linked

@alcinnz

so for example, if you wanted to look up "issues.bop/1608963724" to see bop's open issues, you would go to the hosts legend and find out where issues.bop is

it may be configured as something like:
* distributary.network/bop/issue
* ~/src/bopwiki/issues.bop/
* etc

(probably, setting a Web one would cache it at a local one.)

and you could just run "bop open issues.bop/1608963724" to find the open issues entry in your downloaded source code tree

(none of this is implemented yet)

Sign in to participate in the conversation
FLOSS.social

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).