I've never piloted one, but I'm inclined to think that a coracle would be very hard to steer. No rudder, no keel, the thing is circular, it's not exactly a seagoing vessel. I've found the same to be true of my eponymous software project. I have many definite ideas of where I want it to go, most of which are in tension with one another. Plus, I'm prone to getting distracted by adding new features that aren't really core to my mission (whatever it is).
What it ain't
That fact was brought home to me this week as I worked for the nth time to repair the damage my refactoring did to the public chat feature in Coracle. This was the first feature I added as a response to popular demand and hype over a new NIP being added to nostr, way back in December 2022. Coracle was (I believe) the first general-purpose client to support public chat, which I hoped would bolster its notoriety.
I don't know if it helped Coracle's popularity, but it has cost me several weeks of development time in maintenance and abstraction cost since it was introduced. While it wouldn't be hard to apply the same content filtering work I've added to feeds in Coracle to chat, I'm not sure I want to continue to have my time stolen by sunk cost. And with the increasing frequency with which chat groups are being hijacked by spammers of various kinds, I no longer have the option of leaving chat alone.
So I've decided to remove group chat from Coracle. The implementation is still available, at chat.coracle.social, but unless a wild maintainer appears, it won't be receiving any updates for the foreseeable future. Chat was never a goal of my project, and while it may be one of the more popular features of Coracle, it's one of the least crucial.
This is just one of many illustrative features. In the same release in which I removed chat, I also added a background music player for kind 1808s. This is equally frivolous — but even more fun. It will likely live for a while, and disappear again someday.
Set a course for ???, warp speed
Now that Coracle is basically working™️ I need to take a step back and figure out what I want it to be. Even if I don't know where I'm headed, I'm still moving pretty fast. In order to make the best use of my grant from OpenSats, it's imperative that I at least have a mission statement.
In explaining to Vitor why I was removing chat, I accidentally articulated a pretty good one:
<span itemprop="mentions" itemscope itemtype="https://schema.org/Article"><a itemprop="url" href="/nevent1qqsfwxqv4qq5ajdx8yaksg2fwcw0enpykxvkl9kf2meqgheaq7f3ycgpz3mhxue69uhhyetvv9ujuerpd46hxtnfdufeeexz" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1">nevent1q…eexz</a></span>
The reason for this emphasis comes from the people I originally set out to build for: my church community. These people are generally not "internet-native". They aren't active on reddit, twitter, discord, twitch, tiktok, or youtube. To the extent they use social media, they post pictures on instagram, and buy and sell goods on facebook marketplace.
The features required to support a facebook analog are fairly obvious, and include event calendars, private groups, and marketplaces. However, there are a few dimensions to the problem that make building such a product more challenging than building a twitter clone.
Product complexity
One of the most consistent pieces of advice I've received about building a facebook clone is: don't. Facebook succeeded because it bundled multiple standalone tools into a single interface, and tied them together with a single social graph.
This is one of the things nostr solves — no longer do you need an everything app, if you can use micro-apps on an everything protocol. When I built zephyr last week, I was again stunned at how powerful building on nostr is. In half a day I put together something that would be impossible with traditional technologies — because if you don't have the ability to produce content on a centralized platform, you don't have the ability to consume it either.
But protocols feel different from platforms, especially for the layman. The other half of facebook's value add is (was) a simple and intuitive user interface, which not only made the different components available, but made them accessible as well. I don't think micro-apps, web app stores, or nostr browsers are complete solutions to the UX problem. Nothing can replace a design tailored to your specific end user.
Privacy and parochialism
Social graph partitioning is an essential part of designing a social network. In twitter-like applications, an an effective strategy might be described as "whatever". In other words, as long as you are able to 1. connect to the people you want to follow and 2. discover new content, you're fine — there's no need to be exhaustive or exclusive.
But tighter-knit communities require exclusivity. And by "community" I should qualify that I do not mean a reddit-style common interest, but a real locus of interdependence — whether intellectual, economic, or familial. You don't self-select into true communities except by way of a long (sometimes very long) probationary period.
But, as we learned from mastodon's failures, people are also members of multiple overlapping communities simultaneously. This means that an application designed to serve a person in multiple roles across multiple communities needs to be able to address those differing social circles according to their permeability. Enforcing community privacy using encryption might be appropriate for very tight groups like families, while other groups might want more lax rules about content sharing or member admission.
On nostr, relays are an excellent primitive for implementing access controls, and may be sufficient for all but the most private communication. I've also experimented with encrypted groups (nostr-in-nostr), but the juice might not be worth the squeeze — the additional complexity of gift wrapping might not be necessary if relays can be trusted not to leak data.
Two different approaches to group-specific relays could be used, depending on the level of trust required for the community: an Uncle Jim model where one or more admins host the infrastructure, or a virtual relay model where the group admin creates a private space on commoditized infrastructure.
The value of decentralization at a small scale
Now, of course if you have admins, you've basically opted back in to siloed, centralized platforms, unless shared identity is a value add. Single sign on could be attractive, but not overwhelmingly so — I think the thing that makes an identity shared across multiple platforms compelling is the ability to cross-post.
Unless content is protected by encryption, this is always possible, and would be very good for end users. Allowing content from outside a group to be pulled into a group allows the group to comment on it using its own idioms and values. It also enables loose coupling between weakly-related communities (for example a church and the town it is located in).
This would work very well for community groups, which aren't usually too picky about driving engagement, but would work less well for publishers or media brands, even if cross-posting of content would be beneficial to their curated communities. Instead of increasing the value of your community, it could be seen (and exploited) as advertising for competing siloes.
Multiple types of engagement
Finally, there are multiple types of relationship that might be emphasized to a greater or lesser degree in one community vs another. Facebook-style "friends" are generally less focused on ideas, and more on maintaining relationships. I wouldn't want to read what my mom posts on social media, but I do want to stay in touch with her. In contrast, twitter-style "follows" are more oriented towards the flow of information itself, rather than relationships. An application directed at handling both types of "community" would need to respect the difference between the two.
Toward something, anything
With all that in mind, here's an attempt at articulating my vision for Coracle, loosely based on the EOS model (no, not that EOS).
While my focus above has been on individuals as members of real-life communities, in practice many of these groups can be defined by a common interest in a given content "publisher", which is a more concrete (and practical) use case. This might be something as big as a newspaper, or as small as a substack or patreon. The content provides something for members of the group to talk about.
It seems to me that groups that are not content-focused operate in much the same way, except that topics are selected by group members, rather than by administrators. So the general strategy would be to build a product that can be used more informally by primarily targeting content publishers.
Core Values
- Real life > digital life
- Inorganic advertising is cancer
- Encourage purposeful engagement
- Different communities should be distinct, but mutually beneficial
Mission Statement
To enrich the social media experience of individuals in their capacity as members of multiple overlapping real-world intellectual, economic, or relational communities.
Target Market
Small publishers who want to create a place for subscribers to interact with the publisher's (public and paid) content and one another. Media brands who are open to the benefits of cross-posting across siloes.
What does it look like?
- Anyone can create a group hosted on self-hosted or commodity relays, or a mixture of both.
- A mixture of public and encrypted content for a given group
- Cross-posting of public content between groups
- Private content exclusive to group members
- Multiple tiers of group membership
- Configurable access control: admins, moderators, write access, read access
- Invite codes, including referral discounts/rewards
- Integrated calendar events (public and private)
- Integrated marketplaces (publisher merchandise or peer-to-peer)
- Support topical threads (oriented around publisher content) and member microblogging
Goals
- A relay implementation that supports virtual relays with all required access controls
- A group spec that supports granular content permissions and visibility
- An end-user interface that supports browsing multiple groups and non-group content
- An admin interface for group administration
- White-labeled configurable client implementation
Addendum: Ditto
Alex Gleason has been working on Ditto of late, which is first of all a way to reconcile ActivityPub and Nostr using a server implementation that supports both protocols, but which has the interesting side effect of marrying the siloed, exclusive ActivityPub model with nostr identities. This could be a good solution for branded clients and tighter community control, especially since it allows for the use of existing tools from ActivityPub's more mature ecosystem.
I intend to keep a close eye on Ditto as it matures. I hope that even if the two projects have a significant amount of overlap, that the problem space is big enough to allow for variations in execution, especially since Coracle has the ability to be fully nostr-native.
Conclusion
If you're currently a user of Coracle, don't worry too much, I won't be making any drastic changes anytime soon. I do think that the twitter-like, group-independent part of nostr is valuable, at least as a supplement to more cohesive communities. However, in order to achieve such an ambitious project, I'll have to exercise the discipline to remain focused and cut out any fat that accumulates. We'll see how I do.