Home

A Global Social Web

Head's up: I'm actively overhauling my site builder right now. To wit:

  • Most images and lots of links are broken
  • Code blocks don't wrap and don't have syntax highlighting
  • Other miscellaneous formatting and functionality is off

Please excuse the mess while I put things back together

These are scratch notes. I'm using them to help think about possible approaches. I'm also interested in getting feedback. Especailly from folks who aren't straight, white, dudes. I've got that demo represented. All that's to say that this is just a starting point and likely to change over time

I have a basic undersanding of public/private keys and I think the basics of what touches on them will work. If I'm off-base and you know better please hit me up on mastodon

[] Make a note somewhere about multiple sites for things like separting public and authenticated traffic for offering your art.

[] Make a note somewhere about using public/private keys as a way to confirm identies (and trust chains and all that good stuff)

  1. A list of feeds the site produces directly
  2. A list of feeds the site follows (which may be split into two categoires, individual feeds and then neonet sites that are subscribed too)
  3. A public key (from a public/private key-pair)

- Another aspect of this is the IDs for posts/elemnets/entires or whatever they're called in the Atom Feeds. The idea is that those IDs would be accompanied by a hash created by a sites private key that can then be confirmed by the public key.

- Worth pointing out here again is that my current guideline is that you make your site 100% public or 100% private. If it's public, all this info is available. If it's private none of it is.

- If you've got stuff you want to follow but you don't want it to show up on the site people associate with you the idea is that you can make another site.

- In this way, sites become like accounts. You can have as many as you want to make.

- Thinking about spam for a second, I wonder if it's possible to do a bcrypt type of thing where the cost of genererating a hash for a post is non-trivial. With the power of computers today I'm not sure that would have a chance of working, but it's worth looking into. The reaons is that IDs could be used for replies.

- The way replies would work is that anyone could post a replay to any post on their own site. The feed for that page/reply would include the full replay chain for all the posts it's in line with going back to the original. Because those IDs would be the same (and verifiable via the public key) they should be able to be linked up.

- This is where the aggregators come in. If we have https://neonet.neopoligen.com/ and you've registered your site there it would periodically check all the feeds it's aware of (and we could even set up Neopoligen to ping it directly when updates happen). So, it would know all the posts on it's network that are replies to a post you made.

- Then when you open your Neopoligen instance it goes to https://neonet.neopoligen.com/ and pulls down replies for yours posts.

- How do we make that less intensive for the neonet.neopolige.com site?

- Every neopoligen site could be based off it's domain with a signed copy of they key. That way when neonet.neopoligen.com finds a post that's from one of your sites it can add it to the list for your sites. This would be served in a file like:

https://neonet.neopoligen.com/.well-known/neopoligen-replies/www.alanwsmith.com.json5

- Neopoligen would poll that .well-known location and all the IDs for posts that are in reply chains for your stuff would be in there.

- Your version of Neopoligen doesn't have to do anything with them. It doesn't even have to query the service. This is all optional.

- When I get to making the UI for creating a site this will be an explict decision to opt-in or opt-out of.

- You could also subscribe to multiple networks. So, in addition to neonet.neopoligen.com, you could also subscripte to neonet.alanwsmith.com and pick up the replies feeds from there.

- More importanly, you get to chose who you subscribe to. This allows for some a vetting/moderation point. For example, neonet.neopoligen.com could crawl as much of the internet as it can find and aggregate all of it.

- In contrast, my neonet.alanwsmith.com server would be something I curate to only pull sets of feeds for folks who have joined my network. (In this case, the idea is that I've invited these folks to my network, but I don't necessarily follow them so they wouldn't show up in my folks-i-follow feed.

- If I'm thinking about this right, we could use the neonet.example.com structure as a layer of moderation.

- Anyone at any point can reply to any public post, but if you're not subscribed to a neonet that watches their feeds it wouldn't show up in your replies.

- TBD with that on how reply chains would work. That is, if someone who isn't in your neonet replies to you and you don't see it, but then someone in your network replies to them what happens?

- The good news is that with this set up that decision becomes one that's in your control. Your configuration could be set up to show the post that's not on your network, hide it and give you a link to open it, or just ignore it completley. (though, from a UI perspective you'd probably want to have at least some indication that there is a part of the reply chian you're not seeing.

- This also opens the way for block lists.

- Block lists can be configured in various ways:

Starting to write down some thoughts on how a "neonet" could work to make a socal web of sites.

~ fin ~

Endnotes