Pitch: camelus gossip implementation

camelus is a microblogging app focused on efficiency and ease of use.

Problem:

Existing mobile client are slow, use a lot of data and drain the battery. Almost all mobile clients connect to a static set of relays. Therefore, giving only a limited view inside the network and at the same time consume a lot of duplicated data.

Solution:

Use the gossip model to connect as efficiently as possible, reducing data consumption by 10x.
Gossip by Mikedilger github

Today, most clients query each realay for all the information a client might need, resulting in a lot of duplicate content. This causes unnecessary stress for your data plan as well as on the relay side.

Using the gossip model, the number of request and duplicate data can be drastically improved.
As soon as alice is aware of relay pubkey relationship, she can query only the information she is missing.
This is also great for decentralization, because if clients know where the content is there is no need to be on the most used/hot relay.

What happened during the hackathon?

During this time period I was busy understanding and implementing the gossip model. I also created a stats page for the interested user. On that page there are three categories: dynamic, static and failing.

dynamic:
dynamic is the gossip model, camelus first tracks where everybody is posing and then calculates the best relays that cover the most relays. Currently camelus is configured to get 2x data for each pubkey => cencorship resistance, this will be configuarbale in the setting soon.

static:
You can still configure static relays, although this is only intended as write. My vision of the network is that a lot of people post to their umbrel @ home as well as some public servers.
If you configure read relays, they receive all requests that are not covered by gossip. This is useful if content or profiles don't include a hint on which relays they usually are.

failing:
These are relays that failed to connect.

Target group:

• non technical people

• people that love the idea of decentralization but at the same time don't want to make compromises in terms of usability

• friends and family of a nostr enthusiast

Future plans:

onboarding expericence

a multi step onboarding experience, setting up profile name && picture this is also neccesary to pick your desired write relays.

search/user discovery

Search and user discovery is currently a huge pain when using nostr. I am also working on an aggregator that is reachable as a relay. A client can send search queries and get information where users are. As a high level concept: google for nostr ;)

contact book integration

Non-technical people are used to the concept that all their contacts are already there. I want to explore different solutions.

trust model

Content moderation will become a problem on nostr. A possible solution could be a trust model. A client automatically blocks other users if their social graph (friends, friends of friends) has already blocked them.

deeplinks

Sharable links that lead directly into camelus or a web page directing the user to different methods how to view the content.

new website (+web services)

Here is a sneak preview of the new website ;) launching soon

If you want to support the development consider donating [email protected]