dr knz @ work

The Share Web A manifesto

The elephant in the room, anno 2024, is that all meaningful interactions currently happen in group chats. People do not trust the traditional world wide web (WWW) as much as they trust content coming from their communities: WhatsApp group chats, Telegram channels or groups, Facebook pages/groups, etc.

However, there is one thing that the WWW has, which is not yet available through file sharing in group chats: hyperlinking. The strength of the WWW comes from our collective ability to refer to remote content and assemble new content from it. Group chats and other community platforms do not currently allow this.

What can we do about this?

What if we considered group chat platforms, collectively, to have become a new transport protocol in replacement to HTTP? How would “the web” change as a result?

Let us imagine, what this share web would look like. Here is a proposal.

ShareWeb - Summary

The ShareWeb is a new information sharing system that merges the techniques of the traditional world wide web and “group chats” to result in an information web with better trust, potentially less misinformation, and likely much less SEO spam. It may also have benefits with regards to more equitable sharing of ad income resulting from sharing links with a wide audience.

The ShareWeb is based on a philosophy similar to the WWW that information should be freely available to anyone. It differs however in that it puts an emphasis on trust: where is the information coming from? who is publishing it? Who benefits when I share or access content? These questions do not have easy answers in the traditional WWW; the ShareWeb aims to address them.

Reader view

The ShareWeb is made of communities, sites which are bundles of documents, and links between documents and sites. “Sites” are analogous to ZIP files or a single traditional WWW site. “Links” are analogous to traditional WWW links. They differ however from the WWW in relationship to communities.

In a nutshell, the ShareWeb utilizes existing community as the primary “location” for sites. It is organized so that members of a shared community can freely access site contents “inside” their community, but sharing a site across communities entails extra verification and trust mechanisms.

To view ShareWeb content, readers start from their community platform (e.g. a group chat) and click/navigate a “site object” that was previously shared in their community. It may initially appear like a shared file, and navigating it opens a ShareWeb content browser. Within that browser, they can view the content and freely navigate to other content inside the same site. So far the experience is equivalent to that of a group of related web pages inside a traditional WWW site.

Where ShareWeb differs is when it comes to access permissions and linking between sites.

From a reader perspective, this relates to sharing sites. Two types of sharing are supported: sharing content and sharing links.

When sharing content the entire site bundle is shared from one community to another, e.g. via “message forwarding” in the community platform.

In this type of sharing, the ShareWeb browser ensures that the reader can inspect where the site is coming from: which community it was originally published on, and which community(ies) it was forwarded through, etc, like they could inspect the origin of forwarded content in a group chat. If the site’s contents are modified after they were shared, readers are also informed of when and who last modified the contents.

The other type of sharing is sharing links. This is when a link to a community site is shared with another community, possibly on a different plaform (e.g. sharing a link to a site shared on WhatsApp via a Telegram channel). These links have a special structure, so that they can be included in one site to refer to content on another site.

When a reader is using a ShareWeb browser, and they come across a cross-site link, and they decide to navigate the link, two things happen:

  • in the background, the ShareWeb browser uses the underlying community platform to request the target site data. This in turn verifies, through the community platform, that the reader has access to that community’s contents. For example it will check that the reader is a member of that community, or that the “share permissions” on that object allow access by external viewers.
  • the ShareWeb browser also ostensibly displays that a cross-site navigation is ocurring, where the target content is coming from, and which community is responsible for it.

The resulting UX is in many ways analogous to the UX of navigating WWW sites. However, a major difference is that at all times the reader navigates with confidence they are only seeing content that was published via their communities, presumably in accordance to these communities local bylaws, codes of conduct and/or publishing guidelines.

Technical view

The ShareWeb is an application layered on top of existing group chat protocols with file sharing, considered collectively as a transport protocol.

The technical components of the ShareWeb are:

  • a new URL scheme to represent hyperlinks.
  • software that serves as ShareWeb content browser for readers. This can be possibly implemented as a customization of existing web browsers.

URL scheme

The URL scheme has the following components:

shareweb://@<platform>:<community>//<site-ID>/<document-path>

For example:

shareweb://@telegram:12313114//shared-pictures/cat.jpeg

Refers to a file cat.jpeg inside a site called shared-pictures, shared inside the community identified with code 12313114 inside the Telegram network.

The scheme prefix is shareweb://.

The <platform> part is a standardized name for the underlying chat platform. For example, whatsapp, telegram, facebook, slack could be valid platforms.

The <community> part is a code that refers to that community on the platform. This should use stable alphanumeric codes to ensure the stability of links instead of the user-facing community names that often change over time. Note that the common platforms in use today all have stable internal identifiers to refer to communities and these would be appropriate for use here.

The <site-ID> part is a code that refers to a shared item on that community.

The <document-path> part refers to a location inside the site and is defined like the path + query components of a WWW URL.

Browser navigation behavior

When navigating a ShareWeb URL, a ShareWeb browser operates as follows.

If the reader is currently viewing a ShareWeb site and the URL is relative to the same site, the target content is displayed directly.

Otherwise, the following steps are taken:

  • the browser attempts to reuse a session to the target platform. If the reader does not have a session on that platform yet, they are invited to create one or log in using that platform’s regular flow.
  • within the platform session, the browser performs a “document retrieval” API call mentioning the target community and site-ID. It is expected that each platform supports document retrieval via APIs in this way. This is currently true of all major platforms in use today.
  • in the case when the reader does not have access to that content (e.g. they are not a part of the community, or the content was not shared with them), the browser then asks the user what they wish to do: they can either request access; or display a stale copy (if a copy was previously downloaded already); or automatically search for a similar site on other communities. The latter is described further below.
  • the browser saves a local copy of the file retrieved in this way. The platform is responsible for telling the browser what is the file format, for example a simple file or a ZIP archive. We assume compatibility with regular WWW storage formats.
  • the browser then uses the document path to access the content inside the downloaded file(s).

The local copy is only stored temporarily and deleted when the viewing session ends, such that access at a later time causes a new request through the platform. This ensures that communities can revoke access to their content.

Mandatory browser display features

When displaying ShareWeb contents, the browser must always provide easy access to the following:

  • the name of the platform and community the content is loaded from.
  • the time when the site was shared on the platform.
  • who inside the community shared the site inside the platform.
  • any other relevant details otherwise provided by the platform about the origin of the document containing the site’s contents.

Sometimes it is possible for a content item to be composed of items coming from other sites. For example, a document on one site may contain an image included from another site.

In this case, the browser must still communicate that parts of the contents are external to the reader. This can be done e.g. via a UI control that causes an overlay to be displayed on top of the content to highlight which parts are local and which parts are external.

Compatibility with the WWW

Existing WWW pages can be integrated inside the ShareWeb network as if the WWW URL was prefixed by shareweb://@web:

For example:

https://google.com/?q=cats

can be processed by a ShareWeb browser as if the link was spelled:

shareweb://@www:https://google.com/?q=cats

which is analyzed as follows:

  • <platform> to be set to www, which selects the API back-end for the request to be “traditional” web protocol.
  • <community> to be set to the URL scheme of the original WWW URL (e.g. http:, https:, etc), which determines the application protocol to use.
  • <site-ID> to be the user/host/port combination in the original URL.
  • <document-path> interpreted as usual.

There are a few benefits as to why a reader would prefer to use a ShareWeb browser to navigate traditional WWW URLs:

  • the ShareWeb browser is more transparent about the origin and ownership of the displayed content.
  • the ShareWeb browser would support further shareweb:// URLs in the WWW pages, resulting in seamless navigation across WWW content and community-hosted content.
  • the ShareWeb browser can use the reader’s existing communities to find substitution links for outdated/superseded content on the WWW.

The ShareWeb limits spam and can result in more equitable revenue sharing

Besides the shareweb:// hyperlink, a key feature of the ShareWeb is the “related site search” described above. This feature allows the ShareWeb browser to delegate to the reader’s communities how to interpret cross-links and perhaps substitute a hyperlink with another.

Even though that feature is envisioned to be primarily a way to preserve access to information when communities shut down, it is far more versatile.

For example, substitution links can strip unwanted advertisement tokens from WWW URLs and increase privacy for all their community members.

It could also add affiliate marketing tokens that benefit the specific communities that the reader is a part of. This could help redistribute income: local communities could benefit from the browsing behavior of their members. Conversely, members could use their membership preferences to choose which communities benefit from their navigation behavior.

This system would also be properly privacy-preserving: the ShareWeb browser would be aware of which substitution links have been published on a reader’s communities but would not report back to the communities which substitution was effectively used (if at all).

Conclusion

Users spend most of their time and their trust online in their private communities and it is about time that information sharing evolves accordingly.

The ShareWeb, as proposed here, is a natural evolution of the traditional WWW in this direction. It proposes to layer a new web browser technology on top of group chats from different platforms, through a standardization of cross-site URLs and the behavior of a chat-based content web browser. It does not require any new centralized systems: all the data is moved around using the existing chat platforms. It does not depend on a single software program: any web browser would be compatible with the ShareWeb if it is able to display shareweb:// links and properly communicates the origin of content to readers; both could be achieved using extensions inside existing browser technology.

Would you like to help build the ShareWeb? Contact me!

Like this post? Share on: Twitter ❄ Hacker News ❄ Reddit ❄ LinkedIn ❄ Email

Comments

So what do you think? Did I miss something? Is any part unclear? Leave your comments below.

Keep Reading

Reading Time

~10 min read

Published

Last Updated

Category

Research

Tags

Stay in Touch