An app to demo social features with Radiks


#1

Hey folks, I made another app to demo what you can do with radiks. This time it’s a more social app, with features like real-time updates and social functionality. It’s called Banter.

Read more about it or jump straight to Github.

(Note that this is just an app to demo radiks, and is not eligible for App Mining).


#2

@hank - thanks - this looks really interesting. I’ve been wrestling with all three of these problems in the art marketplace we have been building. Collaboration in particular say between a buyer and seller with no prior relationship and no centralised db is very tricky. Look forward to getting some time to take a closer look at radiks and how we can leverage it in the future.


#3

Thanks for the kind words. Definitely reach out if you have any questions or would just like to chat about what that might look like in your app.


#4

Bravo!!! :heart_eyes::heart_eyes::heart_eyes:


#5

Well done!

I was thinking of this, because a “centralized” indexing service rids the need of inboxes in terms of seeing what everyone else is posting/commenting on “public” posts, but at the same time it is unfortunately not decentralized.

Do you have any ideas on how you would decentralize radiks in this way? I personally have no idea if it is even possible, just wondering about your thoughts.


#6

The next step would be to find a way for a set of Radiks servers to replicate all their state to one another, so that as long as you can reach any of the app’s Radiks servers, you’ll be able to get all notifications and see all state.

To do this, there would need to be a way to do the following:

  • Discover the global set of Radiks servers for an app
  • Rate-limit updates and events so that a malicious user or misconfigured server can’t just DDoS the app’s Radiks servers.

We could do (1) by creating an app-specific namespace, where each “name” was really a pointer to a Radiks server’s URL. We could do (2) by defining a special “admin” name in the app-specific namespace that records the rate-limits.


#7

Yes, what Jude said. P2P communication between Radiks servers is totally possible, but the hard part is how to do it right. Preventing DDoS is the hard part, I think.

It is also possible for Radiks servers to implement their own rate limiting logic, instead of some ‘admin’ server doing the rate limiting.

It is possible also for individuals users to try and DDoS a radiks server, just like they could with any other server. Radiks servers should be able to rate limit individual users, either by IP, Blockstack ID, and/or a combination of other things.

Once we have Stacks smart contracts, I think the best way for radiks servers to sync is via a smart contract, where they can periodically broadcast the changes they’ve seen. Since there would be a small cost with that, it would at least partially prevent sybil attacks. I’d still like to implement p2p sync before we have smart contracts.

Another hard part of p2p sync is that users can’t get their same private key across different domains. This would mean each user can only log into one radiks server. Collections will totally fix this, though.


Search and Discovery of User-Owned Data (EU funding)