libresh / catalogue Goto Github PK

I like the idea of JSON-LD, but I see a problem with ownership of data. Specifically your example of the wordpress logo thousands of people on the net now trust one machine to provide the logo for their services.

Similar problem is if some ISP hosts a bunch of services and to make it searchable people need to link to it. Then the ISP merges with another and all of a sudden a lot of your links go down. The ISP that offers its services is essentially dependent on a 3rd party to index their json.

I would also note that as we go into the new year we hear more about countries and ISPs limiting access to information. Even in Europe ISPs censor. Censorship to the metadata files would be a very potent attack against this system.

I would suggest a two pronged approach to solve this:

1. Duplication of meta-data by many of the "nodes". This makes searching / comparing offline a LOT easier, this makes it possible to see what was lost when a website goes down. Last this solves the problem of discoverability. It becomes push instead of pull.

2. using public-key cryptography to sign the JSONs, or sign changes in order to establish ownership. What you are looking for is that if a provider changes his name or logo that this is a change that is signed by the provider and the world only accepts a valid signed change. This solves the problem of trust. Instead of having to trust the json-ld links, the DNS and the hosting provider to always and to everyone provide the same output, a series of nodes as mentioned in point 1 will distribute it after checking the signature.

I'd guess that 90% of the current design can stay exactly as you already designed this. Which is awesome, it would likely be an addition of crypto-proofs and a mindset to not trust that is needed to change.

nextcloud/website#6

In libresh/awesome-librehosters#7 we understood that we need a structured survey of the otherwise lossely collected librehosters group of groups. The textual form seems insufficient to conduct a strategic fact collection to map out the field.

That issue holds precious ideas on modelling questions, that may be of use here.

Further approaches are listed in https://github.com/libresh/catalogue#application-solutions

Following on with this aids the overall understanding of possible cooperation vectors within the assumed https://framagit.org/librehosters federation.

nextcloud/website#5

Following the discussion at https://mastodon.indie.host/@lalop/99885178481926478, I think it's important to allow applications to define and use arbitrary metadata, in complement of the standard subset that will be agreed upon.

While some metrics/data are relevant to most if not all applications/instances (user count, open signup, uptime, etc.), some are only relevant to specific applications yet very important for end users.

For PeerTube, it could be the user upload quota, for Funkwhale it could be the library size (how much artists, tracks, etc), for Mastodon it could be the number of other nodes an instance is connected to, etc.

What I'm suggesting is to dedicate a key in the JSON-LD payload to put this project-specific data, so it can still be accessed and collected.

Work on the following:

• expose instance metadata as json-ld
• add metadata to RocketChat website

mastodon/mastodon#6739

This repository is called catalog, which is the american english (AE), global dominant and hegemonic form of the english language used and adopted more than often.

Since we try to establish small and independent cooperations, it could be favourable to use the more nuanced british english (BE) forms in our communication, since they read nicer and have a finer tone.

Additionally we are already working in a secondary or ternary language here, and may want to remind ourselves to the existence of alternative ways of doing and describing things, other than mainstream flattened AE, which is a poorer reification of BE.

Therefore I propose to rename this project to catalogue.

matrix-org/matrix.org#95