Weird-app is meant to give netizens back ownership of the data they’ve created and stored on other platforms. As such, Weird will be an increasingly capable aggregator of disparate web identities and their respective content silos -- siloed no more!

We’re gonna start off dev-centric and gradually work our way through all user types from there. Any identity-serving platform with an open API is ultimately up for grabs.

1: Single-source

Enter GitHub profile, get personal web page.
Create help-wanted issue for how to do the same with gitlab, codeberg et.al.

2: Curated content

Handpick what source-content to use from source platform.

3: Feeds

Add blog feeds (multiple) & twitter/mastodon.
A new tab will be added. See linksapp-fresh.

4: Multi-source

Add itch.io, stackoverflow, deviantart. Refine source-curation to facilitate easy combination of multiple sources.

5: Advanced feeds

Add getpocket/raindrop and pocketcasts/listennotes for ‘what I’m reading / listening to’ feeds.

6: ALL THE SOURCES

By this point we will have some sense of the best practice for adding additional sources, probably arriving at some sort of standardized plug-in system & docs to facilitate self-serve. First and foremost for devs, but also with an eye towards regular users.

Further reading:

• https://indieweb.org/POSSE

The Network is effectively a global jobs board, but for mutual collaborations rather than work-for-hire.

Easiest way to prototype this might be with GitHub issues/discussion. I could list my collab projects there.

On my linkspage, I want a ‘Collab’ tab. Clicking it will reveal a list of the 1, 3, 10 (max) topics/projects I’m open to collaborate on.

Mine would look something like:

• Spicy Lobster
  • Fish Folk
  • Shotcaller
• CommunityOS
  • Linksapp
  • Commune
  • Teachersapp

It might need to be split in two:

1. Working on: ..
2. Open to work on: ..

Or (1) need help and (2) offering help.

My ‘offering help’ section is the topics-based one. It goes something like:

• Open game production (talk to me if you’re trying to make and sell an open source game)
• Open comms software production (ttmi you’re making open source communications software)
• Open source strategy (ttmi you’re trying to create a sustainable open source product)

Special interests:

• Open source
• Coops
• Indie gamedev
• Rust
• Godot
• Community

GitHub profiles support topics already, so I’ve added the above to my profile repo.

Related:

• #20

This issue was generated by todo-issue based on a TODO comment in a521236.

The closest thing to what we're trying to make is this: https://home.omg.lol/ (more so than Linktree et.al.)

It's a wonderful site and we hope to be very friendly interop partners with them in the future. However, Weird has a slightly different philosophy, which we might even call a minimalistic theory of change:

• Identity is central to the whole thing. In particular OIDC as a cornerstone.
• All components of the application must be open software. It’s very important for one’s little corner of personal space on the internet to be open enough that there’s no lock-in effect.
• Along with being open, the software must be self-hostable, to enable credible exit.
• While Weird intends to integrate with the fediverse, it also intends to become its own kind of network.

The Weird.one service will be built incrementally, in several stages. Each such stage could take anywhere between 3-12 months to complete. Many can be done in parallel however.

Through various milestones of increasing feature complexity, weird-app will evolve as:

1. an identity keeper: a personalized calling card
2. an identity aggregator: defragment your feeds and profiles
3. an identity connector: Network of Shared Purpose

Identity Keeper

The most effective way to make Weird usable by regular people is to offer it as a regular cloud service. Since all the hard work of auth is already provided for us in Rauthy, our first Job to be Done should be quite simple.

Early adopters: The 1000++ people on GitHub with a linktree page in their profile.

Linksapp cloud-service

• authenticate with Rauthy (which now supports github as an upstream provider)
• HTML5-based WYSIWYG, drag & drop linkspage builder (advanced prior art in editable-website)
• generate page with plain JS/TS; looks like we've settled on Lit.
• store data somewhere (most likely SQLite)
• give each user a unique sub-domain and/or sub-directory.
• As a preliminary step towards identity aggregation, we're gonna make it super easy to verify your domain on Mastodon et.al.

Offline linksapp

Offline is online with extreme latency

Seeing as Weird is all about online identity it doesn't quite make sense for the app to be all the way local-first, but we do share a lot of the same ideals.

Identity Aggregator

As it matures, Weird-app is meant to give netizens back ownership of the data they’ve created and stored on other platforms. As such, Weird will be an increasingly capable aggregator of disparate web identities and their respective content silos — siloed no more!

We’re gonna start off dev-centric and gradually work our way through all user types from there. Any identity-serving platform with an open API is ultimately up for grabs; POSSE provides some prior art here.

Early adopters: Fedizens in need of personal websites.

Feeds & profile collection

1: Single-source

Enter GitHub/GitLab profile, get personal web page. The GitHub equivalent of https://www.polywork.com/

Screenshots

2: Curated content

Handpick what source-content to use from source platform.

Some initial prototyping for this was done in uda-api and node-uda.

3: Feeds

Add blog feeds (multiple) & twitter/mastodon.
A new tab will be added. See linksapp-fresh.

'Hey Creators, Please Make Firehoses!'
https://github.com/jonbell-lot23/rssblend

4: Multi-source

Add itch.io, stackoverflow, deviantart. Refine source-curation to facilitate easy combination of multiple sources.

5: Advanced feeds

Add getpocket/raindrop and pocketcasts/listennotes for ‘what I’m reading / listening to’ feeds.

6: ALL THE SOURCES

By this point we will have some sense of the best practice for adding additional sources, probably arriving at some sort of standardized plug-in system & docs to facilitate self-serve. First and foremost for devs, but also with an eye towards regular users.

Feed integration

Unlike the pulling in of various feeds as described above, it's a different task entirely to be a feed source.

ActivityPub

Our most likely trial run of this will be with https://github.com/superseriousbusiness/gotosocial because of:

• Feature completeness
• Mastodon compatibility
• OIDC
• Focus on safety features
• Eminently self-hostable

ATproto

At some point we will run our own Bluesky/ATproto PDS. However, our first foray into this protocol will most likely be via bridgy-fed.

Blog

Eventually, it will make sense for Weird to offer its own blogging plugin as a built-in option instead of deferring to external integrations. Becoming a blogging engine is also indicative of other CMS capabilities.

• #8

Identity connector

• #3

We have to disable it for now because it breaks the OIDC client flow.

This issue was generated by todo-issue based on a TODO comment in ef86d90.

Rauthy supports signup via external authentication providers.

Seeing as Weird/Rauthy is its own Identity Provider it may seem nonsensical to support signup via the closed-source incumbents. However, social sign-ins are not oppositional to Rauthy’s value proposition if you think of them strictly as an onboarding tool rather than a default method of sign in.

For Weird we would like to use Rauthy to eventually become our own standalone OIDC provider to compete with the IdP incumbents (Google, GitHub et.al.) in our own small way. But for first-time user registrations, it’d be a mistake to not support the “usual suspects” as a signup method, as that’s what the vast majority of people are used to, including on Weird’s competitors like linktree and biolink.

The proprietary login options could be challenged post-signup; in Weird’s case we’d wait maybe 2-3 months for the user to fully commit to our service, and then pop the question:

“Do you want to upgrade your login with more security and privacy features? Switch to our Weird-ID for passkey login, MFA and zero tracking!”

Essential auth providers

• GitHub
• Google
• Azure (Microsoft)
• Facebook
• LinkedIn

Other

• Discord
• Slack
• GitLab
• Apple
• Twitter/X
• Spotify
• Tidal

longer descriptions are not text-wrapped:

description is styled wrong in light mode:

• Manual deployment
• Automatic deployment to GitHub Pages
• Automatic deployment to Cloudflare Pages
• Automatic deployment to Deno Cloud
• Automatic deployment to Netlify
• SaaS

See also the example set by Publii in #7:

Further reading

• https://developers.cloudflare.com/pages/framework-guides/deploy-a-blazor-site/ — Deploy a Blazor WASM application
• https://garagehq.deuxfleurs.fr/

A tiny linksapp is an excellent way in to what can easily become a much larger CMS story along the lines of WordPress, Strapi, or even Pocketbase.

The linksapp approach facilitates a very gradual way into this bigger thing in a piecemeal manner.

On the local end #7, we can engender ideas from the likes of Publii and Tina, but minimized down to linkspage size.

Looking towards the more distant future, maybe the best example of a modular, progressively enhanced, developer-centric CMS is Statamic:

Statamic 3 is built as a highly extendable, standalone capable, Laravel CMS package. If you’re already a Laravel developer, you’ll feel right at home extending core features with Models, Service Providers, and Middleware. You can even drop it into existing Laravel applications to add a full CMS in seconds. But you do not need to know Laravel or PHP to use Statamic.

https://statamic.com
https://github.com/statamic

Similar ideas exist in Primo, which combines the best of static and dynamic by relying on a database for fully integrated editing and authentication UX, but still exports to a static bundle that can be hosted practically anywhere.

First iteration:

• https://dev.to/harshmangalam/build-your-own-github-using-deno-fresh-and-github-rest-api-32h6
• https://crd.so/

Final form:

• https://www.showwcase.com/
• https://twitter.com/sushrutkm/status/1577612579236872192

See also https://devtr.ee/

This issue was generated by todo-issue based on a TODO comment in bd63e3c.

An important part of Weird is the ability to log into other websites with your Weird account.

Right now Rauthy, the auth server used by Weird, is experimenting with implementing the extremely work-in-progress FedCM protocol, which, if successful, might allow users to log into existing sites with their own choice of identity provider, instead of only being able to sign in with Google/Apple, etc. That's a ways out, as the spec has not yet been finalized and only one browser (Chrome) has experimental support for it.

In the meantime we also want to allow people to Login with Weird using the existing OIDC standard. In order to make it as easy as possible for other sites to add "Login with Weird" buttons, we are going to support "ephemeral clients" from the Solid OIDC spec, which allows you to set the client_id to a URL that returns a JSON doc matching this Rust struct, to automatically register the client.

In other words, this lets apps add a "Login with Weird" button without having to do any specific registration with our Weird server, so that people can integrate Weird login without needing to coordinate with us or create a Weird account. This saves both us and them work.

We'll have to test to make sure that's an option for all of the services that we want to be able to integrate with Weird. It's possible not all of them will support the extension, but we can evaluate that is it comes.

This issue was generated by todo-issue based on a TODO comment in c5def63.

This issue was generated by todo-issue based on a TODO comment in 278f0fd.

🚧 rewrite pending 🚧

Prior art:

• https://getpublii.com/
• https://kinsta.com/devkinsta/
  • https://kinsta.com/blog/install-wordpress-locally/
• https://localwp.com/
• https://news.livebook.dev/introducing-the-livebook-desktop-app-4C8dpu

The closest equivalent to what we’re doing is Publii. This is also related to #6.

Our v1 MVP will be radically simpler than any of the above, as all we are managing is a single-page linksapp.

The initial v0.0.1 prototype however could literally be just a single button that says ‘Build Site’. For starters we just wanna be able to do what is currently done with two lines in the terminal, with one click of a button.

The installable app will be made with Tauri.

Weird serves three different functions operating in conjunction:

• #2
• #3
• #4

aka the Big Three.

We will work on all of these interchangeably, but our primary focus for a v1.0 will be a personal web page.

This issue was generated by todo-issue based on a TODO comment in d72168d.

Relying Parties is OIDC-speak for web apps.

We are testing for compatibility with the following RP apps:

• Forgejo
• Linkding
• Miniflux
• Kitsune
• GoToSocial, pending superseriousbusiness/gotosocial#2225
• OpenGist, pending thomiceli/opengist#227
• Linkblocks, pending raffomania/linkblocks#51
• Shiori, pending OIDC support
• Mattermost
• Matrix (Conduit), pending OIDC support

As I was looking into the GitHub pages integration, I found that the Web Flow for logging in with GitHub requires a server-side component to be secure by default. ( See Discussion. )

We can work around this by using the device flow for logging into GitHub, where our app will display an 8 digit code that the user must type into a GitHub login page to authorize the app. That's not too bad, but it started me thinking whether we might run into something similar in other backends, that we might not have an easy workaround for.

Since we are already required to communicate with hosted online services, if we are dpeloying to them, I was thinking that it wouldn't be a hurt to the user-experience or offline-first solution to have a Deno app that we run on Deno deploy that is in charge of actually publishing to public cloud backends such as GitHub Pages, Netlify, and Cloudflare.

The idea is that this app, let's call it EasyPages, is the simplest possible interface to create a new website for our supported backends, where all you do is upload a zip file of the website that you want to deploy, and it will take care of the rest.

When using the Weird app locally, you would have the option to export the site to a local zip file, or deploy the site using EasyPages, and it would open up an EasyPages window that would walk you through the rest of the process, except that the Weird app would save you from having to save the zip separately and then upload through the UI, because it already has the zip ready and can send it to EasyPages for you.

I'm thinking of trying out a POC for the GitHub pages deployment using Fresh, and I don't think it'd take long to see how well it'd work. Let me know if you think this would be a good or bad direction!

What's the value-proposition of Weird? Especially Weird as an identity provider. And what's Weird's relationship to Commune?

Weird does something for Commune that other platforms don’t dare to do: It separates your core identity from the main-attraction platform. All identity providers are used to have some kind of tight coupling between identity and a service:

GitHub: ID + git
Discord: ID + chat
Gmail: ID + email
Facebook: ID + social network

This tight coupling weakens our digital sovereignty. Even if I stopped using gmail for email, I still rely heavily on it for my authentication to hundreds of sites & services. It’s part of their lock-in scheme.

Gmail et.al. has made identity confusing, because they've made it seem like it necessarily comes coupled with something like email or a social network. But identity should stand on its own, and it is paramount that it's not owned by a megacorp because there's no stronger lock-in effect than ones online identity.

So Weird is kind of a compromise. We acknowledge that identity on its own is somewhat lacklustre, at least in the current landscape. To be competitive, we pair identity with what is arguably the root identity of ones online presence anyhow: The personal webpage.

https://blog.jim-nielsen.com/2022/other-peoples-websites/

Being an identity provider is essential, because I want to be set free from my Google/GitHub dependence. That cannot happen overnight since most sites need to explicitly add additional options, but a lot can happen in the 'indie web' that I now mostly hang out in, e.g. the fediverse and the like. A lot of those apps don't provide any SSO login at all, but they absolutely should, and it's hurting their onboarding capabilities.

https://socialhub.activitypub.rocks/t/autonomous-identity-for-the-pluriverse-based-on-oauth-oidc/3675

As a contacts-based social network, Weird is in essence a CRM. More specifically a personal CRM, as opposed to business/enterprise.

Examples include Dex and Monica (open source). There's also the open source Twenty for businesses.

Personal (C)RM

Monica knows very well who it's for:

Monica is for people who have jobs, a family, and are busy trying to find a good work/life balance. So busy, that they don’t have time anymore to remember to call a friend, say happy birthday to a nephew, or remember to invite someone special for dinner next week. The older we get, the more life gets in the way. It’s sad, but it’s the reality.

I created Monica to help these people.

It just so happens that it isn't for the likes of me, who just cannot be bothered to actively keep people-notes of that sort 🤷‍♂️ I live and die by muddling through the mess.

The more information you put in Monica, the easier it will be to remember everything. Monica provides an easy-to-use interface to store everything you know about your loved ones.

My connections shouldn’t have to play detective with a special file on me that they fill in with more data after each of our conversations. If I’ve met you, there’s like 100 basic datas I’d gladly share openly with you, no questions asked.

In contrast, as we will keep stressing; Weird is not a manual data-entry app. It aims to be 100x more purposeful than Facebook, but it still functions in largely the same way: Click the ‘connect’ button 🔘🙋

For anyone I connect with, Weird will send a request for various datas from that new connection. It's up to them how many of those requests they'll grant (which can be done in bulk/groups for ease of use).

I want more of those data notes to be automatically unlocked both ways as me and my connection raise our mutual trust levels (scope grants) over time.

In essence Weird and Monica/Dex are trying to do the same thing as far as 'relationships management' goes, but Weird favors a scopes-based approach wherein connected peers can incrementally exchange more personal data as the connection strengthens.

Community CRM

There's also about to be a vacuum left by Orbit, as they've been acquired.

• https://orbit.love/article/community-crm
• https://orbit.love/model
• https://orbit.love/blog/the-future-of-community-is-distributed

🚧 rewrite pending 🚧

MVP:

• Signup/Login
• Static site renderer
• hosted service
• edit in-place (?)

v1:

• certbot
• scraper
• Social site importer
• automated profiles (github, linkedin..)

What are the key components of a linksapp page?

• Avatar & header
• Description
• Iconic links
• Listed links (tab 1)
• Feed (tab 2)
• ?..

While Weird is innately online, we also want to ground ourselves in the local and predominantly non-digital.

To that end, I've been in touch with the General Secretary (the bossman, if I'm understanding the non-profit lingo correctly) of the Buddhist foundation of Norway. He leads a center here in Oslo which I've gone to a couple times to meditate and socialize.

They'd like to connect local Buddhists who want to practice ‘right livelihood’ as ethical entrepreneurs. It’s part of the Noble Eightfold Path in Buddhism, somewhat similar to the Ten Commandments and other such holy texts. Right Livelihood is essentially about aligning ones profession (source of income) with ones spiritual code of ethics.

They wanna create a very basic network that can play the role of matchmaker for Buddhists in Oslo/Norway/Scandinavia who are interested in creating pro-social businesses together with likeminded practitioners.

The v1 of what they need is basically just an excel sheet, so I've recommend that they keep it as simple as that to begin with. But we're immensely excited about the prospect of this organizing being facilitated by Weird; it’s exactly this kind of local, grassroots networking that we want to emulate in the digital realm! 🌱

They'll divulge some personal information along these lines:

• name
• contact info
• interests
• skills
• location
• capacity (full/part-time)
• compensation (salaried or volunteer)

Based on that they can match people together and get them talking about possible alignments in their mutual ventures.

Eventually our network will be able to make all sorts of smartly automated connections between these people, but for a start just collecting them in a database is enough to let basic filters ("within 5-50km") and manual curators do the rest. It's a closed network, but their data will be available to everyone else on the network (we'll build in public/private toggles for data sharing later).

If this (Buddhist foundation in Oslo committing to a net-of-purpose trial) moves forward, which seems likely, they’re gonna do a bigger sendout to their members around 15. June 2024 🗓️

That gives us a soft deadline to work with. We're gonna try to have something minimally workable for them by that time.

Requirements for this use case:

• #36
• #2 (MVP)
• Personal data information entry
• User directories
• Tags (optional)
• #35 (optional)

For future iterations we'll need need some notion of organisations and special signup links, like weird.one/org/buddhismnorway. That way their signup process would include certain defaults, like a pre-entered buddhism interest-tag, and default-private accounts, as set by the owners of that org.

But for now we'll just set them up on a dedicated instance like oslolivelihood.no. They'll be forewarned that their data is not guaranteed to persist during our pre-alpha, so they may have to re-enter their information at later stages for any number of reasons, like data loss or space migrations.

We need a sparse but eye-catching landing page to greet our earliest adopters. These visitors will be preloaded with some context when they arrive on our site, so we don't yet have to worry about perfectly pitching Weird under the assumption of zero prior knowledge.

The page should cover:

• Weird speed intro (header + tagline)
• Signup prompt (biolink url-claimer style for now?)
• Further reading (info boxes and links to dedicated explainers for Big Three)
• Weird brand identity

First draft:

Weird

Your internet passport (or: Your home on the internet)

[sign up]

Weird is..

• a public ID card; also known as a web page
• independent 'social sign-in' for the indie web
• ..which together enable a network of shared purpose

I'm playing around with a few different tag lines. It's easy enough to capture the essence of 'ID card' + 'social sign-in'. It's hard to also hint at the NoSP in a one-liner, but it may not be necessary, since the Weird experience doesn't start there.

By default, Weird will assume that blogs live externally.

They can be plugged in by RSS feed, featured as article summaries that link out to the source material, or completely recreated (and canonically linked if the ‘local copy’ is not supposed to be the official one).

But some users will want their own blog running on Weird itself.

I just bumped into https://github.com/Lissy93/my-website by @Lissy93 and it checks a lot of boxes for us, so that looks like a great reference.

Combined with Iroh, it’d be a little bit like https://www.planetable.xyz/

Related:

• #5
• #8
• #14

We need our own text for this:

Rauthy should be completely invisible to our regular users.

A linkspage must be customizable so as to become personalized. Related to #9

There are two levels to this:

1. Tweaking the parameters of the standard linkspage layout:
   https://help.bio.link/en/articles/5291280-how-to-create-custom-themes

2. Changing CSS/HTML files:
   https://jetpack.com/support/custom-css/
   Example: https://www.mousereeve.com/