In my development branch, I now have a way to dump an entire evaluated
forest to a big json blob — including assets (which are now
content-addressed). Forester can then be configured to implant such a
blob, if it is given its path on the filesystem. Obviously this is not
the ultimate version of federation, but it was good enough for me to be
able to split off the Forester release notes and related content from my
own forest into a new forest for Forester, which I am hosting at
forester-notes.org.
The thing that immediately strikes me as a wrinkle to be smoothed out is
the following situation.
1. Forester-notes.org should be an independent forest that probably does
not suck in any other forests.
2. Trees on forester-notes.org need to have authors, and so therefore we
need biographical trees in that forest corresponding to the contributors
to Forester.
3. But now, when Forester-notes.org is sucked into (e.g.) my own Forest,
there are two "jonmsterling" trees. It is unambiguous in a technical
sense (they have different IRIs), but this is bad because it disconnects
the graph in a bad way — if you look at (e.g.) backlinks of
"forest://jonmsterling/jonmsterling" you get something different from
backlinks of "forest://forester/jonmsterling".
One potential solution, which I don't think will scale, is to put all
those biographical trees into a dedicated forest that everyone federates
with. But I don't really like this. But I don't know what the best
approach is — maybe there is some idea that involves or relies on
some kind of "authoritative" identity — e.g. the way that orcids and
DOIs work. But I don't know.
Anyway, any thoughts are welcome. This issue is not a blocker, but it
shows that there is room for a bit of deep thought and design for how
the internet of forests ought to work.
Best,
Jon
Hi Jon,
I think (for essentially the reasons you describe) it will be impossible
to have an authoratative source for a biographical tree. The closest
thing that I could think of (at least in an academic context) is where
someone maintains there own website, but even that does not happen
frequently enough to be reliable.
To me, it feels like the way forward is a truly decentralised approach,
with something like a way to reify that information into a view on
a per forest basis.
E.g., suppose that I have a bibliographical tree in forest1 (not under
my control), and in my own forest. I think it's clear that when I look
at my biographical tree in my own forest, I want all the information
there to be things that I control. Maybe when I view my biographical
tree in forest1 it wants to present different information, in
a different perspective. But perhaps forest1 wants to list e.g. my
contact email or something like that. Perhaps it should be able to do
so, but also specify that this information might be overriden by my own
tree with some kind of designate parent and merge mechanism.
So in other words, my forest doesn't know about forest1 but forest1
knows about my forest.
I guess what I am ultimately describing is something like a package
overlay in nix.
The point is, looking at someone's biographical tree should be
potentially different depending on which forest you are looking at it
from, but there should be constructs to inherit data from another tree
in a different forest in the code of that tree.
You could identify when two authors are the same by some kind of query
in datalog (e.g. two authors are the same if they have the same orcid,
or share a common email address, or maybe even an explicit \parent{...}
designation). Then e.g. on my biographical tree on forest1 it could show
links to my biographical tree in my own forest.
By the way, that URL doesn't resolve for me.
Kind regards,
Nick
On 24 Oct 2024, at 11:51, Nick Hu wrote:
> Hi Jon,>> I think (for essentially the reasons you describe) it will be > impossible> to have an authoratative source for a biographical tree. The closest> thing that I could think of (at least in an academic context) is where> someone maintains there own website, but even that does not happen> frequently enough to be reliable.>> To me, it feels like the way forward is a truly decentralised > approach,> with something like a way to reify that information into a view on> a per forest basis.>> E.g., suppose that I have a bibliographical tree in forest1 (not under> my control), and in my own forest. I think it's clear that when I look> at my biographical tree in my own forest, I want all the information> there to be things that I control. Maybe when I view my biographical> tree in forest1 it wants to present different information, in> a different perspective. But perhaps forest1 wants to list e.g. my> contact email or something like that. Perhaps it should be able to do> so, but also specify that this information might be overriden by my > own> tree with some kind of designate parent and merge mechanism.>> So in other words, my forest doesn't know about forest1 but forest1> knows about my forest.>> I guess what I am ultimately describing is something like a package> overlay in nix.> The point is, looking at someone's biographical tree should be> potentially different depending on which forest you are looking at it> from, but there should be constructs to inherit data from another tree> in a different forest in the code of that tree.>> You could identify when two authors are the same by some kind of query> in datalog (e.g. two authors are the same if they have the same orcid,> or share a common email address, or maybe even an explicit > \parent{...}> designation). Then e.g. on my biographical tree on forest1 it could > show> links to my biographical tree in my own forest.
Hi Nick,
Thanks for all this feedback, it is helpful to hear your thoughts.
>> By the way, that URL doesn't resolve for me.
Well, I suppose this may not be the first time that a newly minuted
domain takes a while to propagate into people's DNS caches.
Best,
Jon
On Thu Oct 24, 2024 at 12:14 PM BST, Jon Sterling wrote:
> Well, I suppose this may not be the first time that a newly minuted > domain takes a while to propagate into people's DNS caches.
Ah, I realised what was happening. I am actually resolving the domain
(to 216.40.34.41), but when I openened the link in Firefox it sent me to
https://forester-notes.org/ which does not seem to redirect to the www
subdomain.
The www subdomain resolves to a (different) sr.ht IP, and works as intended.
I checked on a DNS propagation tool online and the records resolve to
different things there too. I think this needs a bit of intervention to
fix.
Kind regards,
Nick
On 24 Oct 2024, at 13:17, Nick Hu wrote:
> On Thu Oct 24, 2024 at 12:14 PM BST, Jon Sterling wrote:>> Well, I suppose this may not be the first time that a newly minuted>> domain takes a while to propagate into people's DNS caches.>> Ah, I realised what was happening. I am actually resolving the domain> (to 216.40.34.41), but when I openened the link in Firefox it sent me > to> https://forester-notes.org/ which does not seem to redirect to the www> subdomain.> The www subdomain resolves to a (different) sr.ht IP, and works as > intended.>> I checked on a DNS propagation tool online and the records resolve to> different things there too. I think this needs a bit of intervention > to> fix.>> Kind regards,> Nick
Hi Nick,
The DNS records you are looking at are correct but irrelevant:
1. It is intentional that the root is resolved to 216.40.34.41, which is
my domain name provider's IP address, whereas the www subdomain is
resolved to SourceHut's IP via a CNAME record.
2. In my domain name provider's configuration panel, I had already set a
redirect that would send users visiting forester-notes.org to
www.forester-notes.org.
3. I cannot explain why that redirect did not fire for you, but the
problem must be on your end somehow. For example, if I run "curl
forester-notes.org", I get the following response:
<html><body>You are being <a
href="http://www.forester-notes.org">redirected</a>.</body></html>%
Best,
Jon
Right, the issue is that forester-notes.org doesn't listen on port
443, so if you explicitly go to https://forester-notes.org nothing
happens (note the https:// part is important here).
You can observe this with the following:
❯ curl -v https://forester-notes.org
* Host forester-notes.org:443 was resolved.
* IPv6: (none)
* IPv4: 216.40.34.41
* Trying 216.40.34.41:443... (hangs)
Kind regards,
Nick
On 25 Oct 2024, at 15:47, Nick Hu wrote:
> Right, the issue is that forester-notes.org doesn't listen on port> 443, so if you explicitly go to https://forester-notes.org nothing> happens (note the https:// part is important here).> You can observe this with the following:>> ❯ curl -v https://forester-notes.org> * Host forester-notes.org:443 was resolved.> * IPv6: (none)> * IPv4: 216.40.34.41> * Trying 216.40.34.41:443... (hangs)>
I see! I will see what can be done about that… Overall I don’t care
about HTTPS here because a forest does not accept or store nor transmit
any user data, but it is not good if people typing
“forester-notes.org” get sent to an address that doesn’t exist by
today’s overzealous browsers.
Best,
Jon