home ~ projects ~ socials

A Vision For The Web

Head's Up

This page is an early draft. I'm publishing it both because I like to work in public as well as to get feedback on the ideas.

Introduction

This post was originally called "A Website Manifesto". It started with the lines:

It's time for a revolution. Not of politics, but ownership, agency, and privacy.

That helped me get started, but it's not the right tone. This isn't A Manifesto. It's a collection of thoughts about the future of the web. Half vision, half roadmap.

In the vision, the nature of the web evolves. Combining ideas from old school personal sites with contemporary social networks. The result is a new environment where individuals take back power over their works and their interactions.

The Goals

I'm starting at the end. What should the web look like? How should people interact with it and with each other?

I've spent years thinking about these questions. I've boiled it down to these goals:

  1. Everyone has the abilty to create personal websites where they can post the things they create.
  2. Websites are connected to each othter to form collections of social networks.

The first goal is done. Anyone can make a website and publish it for free on a wide collection of services.

That brings us to the second part.

A Network Of Website

The idea of networking websites is nothing new. Webringstktktk and Blogrollstktktk harken back to the early years. Just straight up linking has been around foreverother tech. But, we never really connected them. Not in the way that modern social networks connect people.

That's what this post is about.

The People Problem

TODO: Rework to focus on what you can

This post covers technical ideas for how to assemble social networks from websites. What it doesn't cover is The People Problem. How do you get folks to use the network. Specifically, how do you get them to move off whatever is currently serving their needs? What's so much better about the new network that folks are willing to jump ship?

I can think of few possible reasons:

  • artists that want to have more control over their works and content
  • folks looking for places to build communities with moderation tools they have more control over
  • folks who just like to tinker and don't like the constraints enforced by social networks
  • folks who don't want to start over again when they social network they're on inevitably enshittifies

The only thing I know is that it won't be because of "better technology". Peopletktkt writ large don't care about the tech behind social networks. They could give two shits about the differences between AT Protocoltktktk and ActivityPubtktktk. They have no ideological stance on the purity of websites and decentralization.

They just want an easy ways to post and to be where the people they want to follow and connect with are.

TODO: The People Problem Redo

    [] Talk about specific benefits.

    [] The ability to post whatever type of content you want

    [] Collections (e.g. videos, music, their favorite posts, bookmarks, read later, link blogs)

    [] No ads inherent in the network

TODO - The Moral Obligation

    [] Talk about the moral obligation

Starting With The Tech

If I was starting a company, I'd work on the people problem. Trying to figure out specific ways to move folks to my network. Designing to attract them based on pain points and unfulfilled desires. Trying to solve The Innovators Dilemmatktktk

I'm taking a different route. A Field Of Dream's style "If you build, they will come"tktktk.

This history of technology is littered with failed projects that trod this path. Attempts to start with technology and techniques instead of the people problem.

But, I'm dissatisfied with the state of the web. The negative impact the consolidated social networks are having on the world are crushing us. I don't know how to solve the people problem, but I know how to build. So, I'm building what I want to see.

Hopefully, folks show up. If not, at least I took my shottktktk my thing may not work, but if enough of us try someone's will eventually.

The High Level

Building social networks is hard. There's a zillion things to consider. Exhausting numbers of critical decisions.

I'm punting on most of it. The goal is to stand on the shoulders of giants. Using existing tech as much as possible. Adding as few new components as possible to glue them together.

It starts with two files. One for a table of contents. The other for an ID.

The Table Of Contents File

Websites have a few ways to programmatically communicate information about their content. Sitemapstktktk, and meta data elements identifying RSS feeds, for example. The Table Of Content file (located at /.well-known/neb/toc.json5) does that and more. It provides the foundations for networking sites together.

Specifically:

  • Metadata about the site
  • The feeds a site has
  • The feeds a site follows
  • The capabilities a site can perform

Table Stakes

The site metadata is a standardized collection of information site owners can fill out. The name of the site, a description, an avatar, etc...

The list of feeds is just that. Links to any public feeds available on the site.

That metadata and feed lists are packaged a little differently, but they're generally available on sites today.

The list of followers is where the new stuff starts to kick in.

The Following List

Folks won't use a network if they can't find people to follow on it. The following lists are designed to remedy that. They provide links to other feeds that a site follows publicly.

It's like Blogrolls, but standardized and packaged as raw data for processing instead of links on a page. Each site that has a Table Of Contents provides a new jumping off point for finding sites to follow. You can go as far down the rabbit hole as you'd like.

The Capabilities

There's a variety of servers and services that host websites. They offer a corresponding number of differences between them. For example, my site is a "fully static site"tktktk at least at press time. Every page looks and functions the same for everyone. Other sites are "dynamic". They can offer things like logging in to see personalized pages.

Completely duplicating the functionality of modern social networks would require every site to be dynamic (e.g. so they could receive notification of follows and replies). However, there are some aspects that static sites are capable of on their own: (e.g. publishing the core feeds of content).

The list of capabilities in the Table Of Contents files provides the details about what a site can do and how it can interact with other sitestktktk includes endpoints. Different sites use that information to determine how to work with each other.

The ID File

Communication between sites requires the ability to confirm the identities. Without that, it would be possible for anyone to impersonate any sitetktktk this ID based approach doesn't eliminate the possibility, but helps reduce the number of ways it can happen.

Each site has an ID file (located at /.well-known/neb/id) that provides the ability to authenticate communications. The file is the public half of a public/private key pair.

Every communication between sites uses these keys to "sign" the contents in a way that makes it possible to validate it came from who it says it came fromtktktk talk about keeping private key private and how to switch them and needing security folks to look at this and how to use bcrypt or whatever to make it take some resources to help cut down on spam.

Pages, Posts, and Shorts

There are three types of content feeds defined in the toc.json5 files. They are determined by their associated metadata:

  • Pages - Have a title, but no date
  • Posts - Have a title and a date
  • Shorts - Have a date, but no title

Pages are used for things like "about" and "contact" pages. They're "evergreen". The idea is that they would be associated with a "profile" of each site.

Posts are traditional blog posts that include a title along with the content. They are dated and generally show up in the feed in reverse chronological order (though, that's not required)

Shorts are like micro-blogs. Little pieces of stand along content that don't have a title associated with them. (Though, there's nothing stopping you from adding h1 elements to make the look like titles)

Beyond the criteria for which types of titles and/or dates, there's no other limits on the content type specified. That means, for example, shorts can be as long as someone wants and include as much as they wanttktktk initial limits for some social media platform were a result of the technology they used. Because the systems were centralized they could enforce this. There's no way to do such enforcement on the open web. Individuals and groups will come to their own norms about usage, but restrictions won't be made at the technical level

TODO: Content Warnings and Spoilers

    [] Content warnings and spoilers will be available both for the overall posts and for specific parts of the content (text, images, and videos) The feed code will be defined as part of the spec. Implementing the functionality must be done by the apps. (Though, maybe you could use detail disclosure elements? That's probably the better way to do it since it would work for regular web pages as well)

    [] TBD on if the spec should include content warning tags for wrappers. Thinking about it, this would be a solid edition the overall HTML spec.

TODO: RSS Payloads

    [] Add details about using RSS as the primary payload type for communications.

    [] Feeds will be RSS.

    [] Updates sent to servers will be RSS as well.

    [] UUIDs should exist for all content to accomodate things like sending updates to followers about edits to content.

    [] Detail standardized extensions and spec them.

TODO: Possible RSS Extensions To Add

    [] site address for content items (which can be used to get the public key via the /.well-know/neb/id location.

    [] hash values of content

    [] hash values of media files

    [] requested web components - the idea being that the HTML with have the component in it but the JavaScript wouldn't load unless the user gives the app permission to do so.

    [] CSS for items (pages, posts, shorts)

    [] CSS for feed level (e.g. preferred font, background, colors for displaying the name in a feed).

    [] Reply chains (and, potentially threading)

    [] Cache chains (e.g. cache locations for media and their original source locations)

    [] Tags for posts (in theory could do tags and categories independently, but that just adds more options without a significant functionality improvement.

    [] Different image sizes (probably not needed since srcset exists)

    [] Advisories about the feed. (e.g. language, adult content, etc...)

    [] Avatars (was originally thinking this would go in the site table of contents, but it's worth considering making them feed dependent. In fact, yeah, that probably makes the most sense. Maybe still have one in the toc as a fall back? not sure about that)

    [] Feed metadata

    [] Tags as an array in an independent node.

    [] For replies, hash the original content that's being replied to. This will help identify if a post has changed since you replied to it. The value will be added into a field in the reply to let other folks know if they're seeing the same thing you replied to or not. (don't try to hang onto the original stuff, that's too much overhead and too fraught since it would give the opportunity for folks to alter what they say was in the original post.)

    [] Add hashes for images. TBD on how this will work with CDNs and other compression because the files will be updated in a way that changes the hash after they feed is created. Not sure there's a good way around that that isn't overly complicated.

TODO: Sending CSS

    [] Provide a CSS payload area in the feeds for posts and shorts.

    [] Allows folks to style the content they send.

    [] CSS would be limited so folks can't do things like cover the viewports in a way you can't get around.

    [] Also provide a CSS payload for the user banner. (It could, of course, be overridden, but would allow a personal touch by default)

    [] No external stylesheets. All CSS must be directly embedded in the feed/post. This prevents changes in external stylesheets from messing with the way things looked when they were published. It also prevents styles from disappearing if an external file is deleted.

TODO: Follow, Replies, Threads, etc...

    [] Standard social network actions are included.

    [] TBD on the details after reviews of different existing protocols and APIs

    [] Spec out threading in the feeds for tracing back through replies

    [] TBD on the way to handle looking at full threads with multiple branches on posts. And when to update them, etc... It would involve some communication back and forth between servers. That's something to solve for.

TODO: The Apps

    This gets to the most interesting part. The way folks will interact with each other. Websites will be the central hubs and distribution points, but may not get a lot of direct traffic from browsers. Apps can consume the feeds more like an RSS reader than a web browser.

    In fact, it's possible to run a site without any HTML pages served over HTTPs at all.

    [] Builder apps

    [] Viewer apps

    [] Combined builder/viewer apps

    [] Different views and filtering

    [] User based stylesheets to customize reading experience

    [] CSS from feeds and overrides

    [] Syncing between devices

    [] Bookmarks for read it later

TODO: Network Relays

    [] sites that provide dynamic functionality that builder apps can pick up.

    [] can provide the back end site connection services for static sites

Caching

    [] Spec caching. The goal is that if someone re-posts, or quote-posts a piece of content then they server up a cached version of the content from their server. This includes any media (e.g. images, videos). This is designed to take pressure off the source servers (e.g. if someone with a ton of followers re-posts something from a smaller account). All caches would have hash checks that are signed with the original site's public key for verification that nothing has been changed.

    [] Caching should work with reply chains too (i.e. if you reply to content your server should pull the entire thread and served cached copies)

    [] Caching will always in include the source of the feed as well so if the cache doesn't validate the source can still be pulled.

    [] Need to get review of the caching approach so folks can help poke holes in it and refine it.

    [] Caching will be at the discretion of the downstream sites. (e.g. they can set their own rules for how big a size files they are willing to cache)

    [] TBD on getting feedback on caching strategies (e.g. how is illicit material handled. Generally speaking the idea behind caching is that it would only happen if someone interacts with a post in a know way where they would see and can make a decision about it, but this needs more thinking.

Decentralized Network

    [] vs centralized. Pros and cons

    [] centralized have more ability to ensure all replies make it to the person that was replied to.

    [] centralized means someone else owns the content and the algorithms and controls what you see.

    [] TKTKTK lots of other stuff.

TODO: Financials

    [] No venture capital behind this. I'm putting in the effort on my own dime. I may look for support at some point, but it won't be from VCs.

    [] I want to take this one thing and remove capitalist motivations from it. Multiple types of business can be built on top of it, but the base layer is something that should belong to everyone without cost.

    [] One possible source of support would be affiliate or white label domain names. That would mean having to pick a provider. Not super opposed to that, but it means making a financial decision that impacts the app (assuming it goes in there)

    [] Hosting is a natural opportunity. I'm not interested in that business at all.

Naming

Naming things is hard, but without a label things are harder do discuss and promote. My current thinking is to use a portmanteau of "network" and "website" to end up with: "nebsite". Everything sounds weird when you first say it. So, I'm going to give that a little time before I make a decision on it.

The overall collection would be called "the neb".

  • Posts are "posts"
  • Pages are "pages"
  • Shorts are "shorts"
  • "post" and "posts" can also be used generically to describe both Shorts and Posts according to context. (e.g. "did you see my post" could refer to a Short.)

TODO: Neb Components

    [] Web Components but with additional metadata to help folks determine what things do.

    [] TBD on if the metadata will be in the same file or an external JSON5 one. Ideally the same.

    [] TBD on how to handle components that require other components.

Why I'm Writing This Now

My hypothesis is that if folks have their own sites which are networked (so they have some of the feel and mental reward system of existing social networks) they'll spend time working on them.

At the core, that's a creative endeavour.

I believe the more time you spend on creative endeavours the more empathy you develop (cause you start thinking more about how other folks will see your stuff). And, the more empathy we have for each other the less pissed will be at each other. That's a direction we could really use right now.

-- end of line --

Endnotes

  • This talks a lot about websites, but a key aspect of the feed stuff and the connection stuff is that it provides a foundation for a new way to interact with the web. Instead of visiting sites directly, apps can be used to browser and interact with sets of feeds. All the content would be on the site as well, but most of the interaction could be done without having to go to it directly.

  • Everything in the spec is open-source. The goal is to get it approved by a standards organization (e.g. W3C) so that it belongs to the world and not to a single person or company.

  • It's worth pointing out that a key aspect of this is that as long as you own your domain name you can move your site at any point to a different hosting provider. As long as it offered the same capabilities the folks who follow you wouldn't even notice the change.

  • There are several security implications and concerns involved here. Part of moving forward is talking with security experts to refine the security postures and trade-offs.

  • There's a bunch of design/interaction work to do. For example, how will threads of conversations work. I'll be basing those decisions off the way other protocols do things and polishing the details in the prototypes.

  • An implicit goal of this vision is to replace existing social networks. To create a new type. One that does away with corporate centralization and control. Replacing them with networks based around individual ownership, agency, and privacy.

  • There's nothing new in this vision. At least, not when it comes to technology. The key differential is the way the parts are connected. And, I expect even those ideas have been considered before. But, being new isn't the goal. Making something that works is.

  • Because this rides on the open web there is no team of moderators reviewing content built into the network. The base level of controlling content is done by filtering content. One way to do that is by utilizing the connection between sites. For example, setting up a filter that only accepts replies from folks a certain number of degrees of separation away (e.g. allowing folks you follow, folks they follow, and the folks they follow to send replies but no one else).

    Another way to filter would be based on folks who follow you. For example by setting up a list of every site that has notified you it's following and specifically selecting to show replies they send to you.

    Built into this approach is the idea of community. You get to decide the members and depth of the communities you participate in.

    Moderation does provide a business opportunity though. Providing it would make a great incentive to sign-up with a company for hosting.

    All that said, getting additional input on how moderation and protection can work will be done as well.

  • There is no accommodation for private posts built into this approach.

    I've got ideas for future ways to handle that, but everything in this version is public. That means, for example, you can't block folks from following you. But, that's not realistically possible on contemporary social media networks either. Someone who wants to follow you can always make another account and if the overall network is public (like it is with Bluesky) they can see your content without specifically following.

  • This approach puts you in control of the algorithms that display your feeds. You're no longer locked into the way a centralized corporate service handles them.

  • The toc.josn5 file uses JSON5 to allow for comments and trailing commas.

  • While CSS is allowed in the feeds, JavaScript should not be. This is up to the apps that consume the feeds, but the guideline it to scrub and remove any code that can execute.

  • One thing I'm thinking about for a future iteration is signing by the hosting provider too. The idea being that hosts could make content moderation part of their offering and seeing that a follow, reply, whatever came from the host would be a stronger signal that it's been reviewed. TBD on if this even makes sense, but it's worth looking into.

  • Running individual sites means having to deal with things like traffic spikes. This is where hosting providers and CDNs have a business opportunity.

  • Advertising will still exist in this world. The difference is that it would be the default. Folks will be able to add it to their sites if they want. (Or, it may be added by a hosting provider in exchange for free hosting, but again, that's the decision of the person who owns the site)

  • There's no analytics built into the overall network. Individual sites can add tracking and analytics but it's not like contemporary social media sites that track everything you do in one place.

    Companies wouldn't be able to watch all the traffic on your site unless you install analytics from them.

  • I expect aggregation services would pop up as well. Sites that collect tons of feeds and filter them based on some specific criteria.

  • Impersonators become easier to detect because they won't have access to the domain and public keys of the actual person.

  • Communities aren't beholden to the whims of the social media companies. They'll be in control of their sites, how they work and the connections they make. The danger of a social media platform changing out from under them is eliminated.

  • My site is 20years old. Part of the reason I'm digging into this is because I'm thinking about the next 20. Given the past performance of corporate social networks I can't see one lasting that long. Websites, on the other hand will be around as long as the web exists (because the web is made of websites)

  • Owning your own site is a pushback against the general trend of enshittification of the web.

  • You can edit your posts.

  • The ability to add CSS means shorts can have their own individual styles

  • The CSS can be applied to more than just the posts. A default set can be used to format the header above each post.

    Of course, folks can override that with their own styles if they like.

  • The reference version of the app will strip any JavaScript from pages, posts, and shorts and won't let it run. With everything you can do with CSS, content will still have way more power than current micro-blogging and social media sites.

    That said, that does do some limiting of the functionality. My thinking is that a middle ground can be found with web components. Specifically, there could be centralized collections of web components that have been reviewed for functionality, accessibility, and security. Individual content pieces could reference the components and apps could load them on an opt-in basis.

    (Of course, it's up to individual apps on how to handle this, but this is how I'm thinking about it for the reference app.) To keep pressure off the repositories, the components could be included in the feeds if they are signed with the public/private key from the repo.

  • The use of public/private key pairs opens up possibilities for direct/private messaging. I'm interested in looking at that, but it's beyond the scope of this initial iteration.

  • Image alt text can now be stored in offical IPTC metadata. I'm thinking the standard should be for apps to add alt text to the metadata fields if there's some associated but not already in the metadata. Would have to figure out how to handle conflicts, but this would help ensure that more images had metadata in general.

  • Apps should look for alt text metadata in images. Alt text in img tags will likely be what ends up taking precedence, but that's TBD.

  • Apps will be responsible for their own storage limits.

  • The approaches envisioned here can be broken down into two categories. Stuff that's required to be part of the neb, and stuff that's recommended to be done in apps. This is, of course, the open web so folks can do whatever they want, but the stuff listed here is how the reference app will behave. Apps that want to be good citizens should behave likewise.

  • Thinking more about communication between servers I really like the proof of work modeltktkt proof of work. Thinking that almost every time a server sends a request to another one that has a payload a proof of work should be required. There might be exceptions for things like pinging a server to know that a feed has updated. The reason not to have a proof of work there is because the receiving server doesn't really have to do anything with that.

    One of the main reasons for the proof of work is to raise the cost of spamming. If the primary set of connection requests cost some amount of computation it will cut down on the amounttktktk at least that's the theory.

  • Should there be a "links" feeds? Something to think about. Not sure if it should be a separate type or not. One reason it might be is so the links can be explicit in the data. for easier parsing, but maybe it would be nicer to have clicking them (and assembling them be more human) Could be a kink of forwarding thing though.

    Yeah, feels like there should be like a "reblog" type thing that's not a reply. Basically both boost and quote post should be possible.

  • I'm thinking a lot about follower counts. They are social currency on contemporary social networks. If I had to move a slider on them between good and evil it would tend a bit toward the later.

    When folks own their site, they could put forth any number they want. If some app makers wants to add that as a feature they have every right too, but I can't foresee adding it to mine.

  • One thing that still needs more thought is if there's a potential connection approach that would act like forums.

    Thinking that one conversation could start as a key then ingest all the things that point to it (or go down a tree from it) and that primary post would act as an aggregator that on sites could re-poll for updates.

    Maybe this is just how things work in general? TBD on that.

  • Seeing someone else's timeline/feed should not require giving out your email address like is required on so many contemporary social networks. It won't be with this approach.

  • Definitely want to be able to add descriptions into feeds at the overall level for the individual feeds (not just at the site level). TBD on if that is already built into RSS or not (I kinda think it is)

  • TODO: talk about resistance to censorship because there's no central location things can be taken offline. (I think that's already mentioned somewhere above, but take a look to make sure)

  • Cover some of the possible feeds folks can set up to get started with ideas. All posts, just posts with certain tags, quotes, bookmarks, favorite posts that rarely change. These could end up being like slashpages where there are some feeds that become kinda standard simply by lost of folks doing the same thing.

References