Questions about basic social network functionality based on Blockstack

Apps
#1

Hey guys,

I have two simple questions around some basic social network functionality built on a Blockstack’s infrastructure.

Trying to sound not too stupid … Graphite, Stealthy, Afari, Travelstack… have all figured that out I guess… so I assume my questions are stupid… upfront sorry for that. Though I have not found any documentation about it so far (please, if something exists on that already, point me to…).
Thanks a lot for helping out.

I am familiar with the classic put / get file system on Blockstack, and the obvious fact that users can read data from other users storages (if the are allowed to), but that they are not able to write any data to storage of another user.
Which means people still can communicate with each other via a method like the one described below (* see clarification notes below), but in order to do so, they have to know about each other upfront. So how do these users intially know about each other?

A) In social network speak… how can A send a friend request to B?

Basically a simple Follow / Following friend request, or a kind of push notification.
Is this possible based on Blockstack, or do we need some centralised database like “Firebase” in between?

An obvious follow up:
Let’s assume we want to build a public forum board like this right here.
B) How can users see content updates from other users, they don’t know yet about
(not yet actively added to their followin_emphasized text_g list), without having an instrumentalized account that is calling the full userbase of Blockstack all the time for updates, and makes the updates accessible for everyone?

Is this possible based on Blockstack, or do we need some centralised database like “Firebase” in between?

Any hints, ideas or suggestions, very appreciated.

(Maybe also an interesting topic for integrating into a Blockstack tutorial?)

*Notes:

Maybe quickly for clarification what I understood so far how users can communicate with each other via the get/put system:.

  1. User A writes some data
  2. User A gives user B the ability to read the data
  3. User B reads the data
  4. User B writes changes, and makes them readable to user A
  5. When user A reads the data, she reads both her data and user B’s changes

Both users have copies of the data, with changes they each made. The app would show user A and B the most up-to-date version of the data in order to preserve the writes made by A and B.

All that is fine, if these users know about each other and about the file that they are supposed to collaborate on.

But how do these user initiate their relationship in a decentralised system?

2 Likes
#2

In both cases, you’d have the users write their respective states (e.g. new content, friend requests) to their respective Gaia hubs via putFile(), and then run an untrusted indexer service that aggregates this information for app. That way, each user owns their own data, and you get the same user experience as a “centralized” service.

I emphasize untrusted because all the indexer is doing is caching information downstream from each user’s Gaia hub. If you do it right, the indexer will store both the data and the signatures stored by putFile() and the clients will use them to authenticate the data on read.

#3

@jude As always, thanks so much for your help :pray:.

Three follow up questions:

  1. For me personally … running such an “indexer service” sounds not to be trivial … scaling, performance… I guess you would write this in something like Python? Or are there any standard solutions “out of the box” that you might recommend? (your are talking to a product designer here :wink: )

  2. Have you considered to make such an indexer as standard part of your Blockstack SDK / API? Sounds like a very basic functionality any service with user communication might need?

  3. A more “philosophical” question in two parts:
    a) If such an “indexer” exists, that basically stores all the “publicly” generated data of such an app at one place, how much can we call this still decentralised?

b) How far would this differ from simply writing and reading “meta data” about a certain content or user (not the full data (!)) into a classic database on Firebase or whatever? Basically also generating an “index” at some central place, but without the crawling?

#4

Every app that needed an indexer built their own. We have a boilerplate one here (in node.js) you can base yours off of: https://github.com/kantai/blockstack-search-indexer/. It will need to be customized to track the app-specific information you care about.

Not at this time, because it’s a very under-specified problem. Each app needs to track different state, with different consistency/availability guarantees, different privacy settings, different durability models, and so on. App developers usually take the boilerplate indexer above and customize it. You should consider reaching out to the Afari, Travelstack, and Stealthy folks for their indexer code if you’re interested in real-world examples :wink:

Indexers have no hard or authoritative state. This means anyone can run an indexer, and the indexer can only read the data you allow to be public. If I was making an app with an indexer, and my indexer was faulty somehow, you could fork my indexer and my indexer client code and make your own. Then, since users already own all their data, they could simply switch over to your indexer and indexer client without interruption.

The Blockstack Way of developing apps is to ensure that users are the authoritative origins of their data at all times. This means any service can act as a downstream cache of user data, but under no circumstances should a downstream service become the authoritative source of user data. It’s fine to use Firebase to implement an indexer, but Firebase shouldn’t store anything that isn’t 100% derived from state in your users’ Gaia hubs.

1 Like
#5

@digitalwaveride, Stealthy works without an indexer/centralized phonebook/signaling server if both parties of a conversation add each other as contacts. This makes true decentralized operation possible.

The main problem you allude to though is solving the phonebook problem. You’re always going to see arguments about how decentralized an App is and a lot of that for social dApps will come down to how they’ve solved the phonebook problem.

Stealthy started with Firebase as a centralized convenience and allowed users to disable it for full decentralized operation. In future, we’re looking to go to the decentralized gun database (https://gun.eco/) and possibly some other solutions.

1 Like
#6

Hey Alex, thanks a lot for the link to Gun! That looks very good.

For Textlibrary I will run currently with the Firebase option to solve the phonebook problem. Taking care that a minimum of data is stored there (basically just ids in order to connect queries) and making sure that all data is also mirrored individually in each of the user hubs. So if someone wants to run an indexer, it’s doable, and Firebase never is an “authoritative source”.

All that said, it would be great if there would be another solution for this.

As @jude mentioned above, there are good reasons why it makes no sense to include “an index” as core of Blockstack, though I still see the phonebook problem as a standard challenge that nearly all platforms will run into. Having some solution that comes as part from Blockstack would be not just convenient for developers, but also it would avoid that some apps might take a shortcut and start creating data pots that in the end keep certain parts of the app centralized.

1 Like