How can we build a decentralized user dashboard?

Ideally we can build a completely non-custodial stack where we never obtain user information beyond what everyone can see on the blockchain. Our proposed SDK and the publisher-side widgets wouldn’t pose any problems here, as they would be implemented on third party websites.

Yet the easiest was to implement a user dashboard would be to host them on a site that we build, which would involve capturing exposed metadata like IP addresses associated with user accounts. Capturing and storing that information is not desirable for a secure and permisionless protocol, if for no other reason that it could serve as a honeypot for malicious actors.

I don’t think it’s a good idea to omit a user dashboard where tribute allocations can be tracked and managed outside of the context of what publishers want to display. Otherwise users might feel out of control and unhappy with the tribute layer. Of course we could leave it to another dev team to make a user dashboard on their own site, but if that weren’t available at launch it would leave a pretty big hole in the ecosystem. I’m in favor of launching a user dashboard ourselves. It might make the overall system more robust if there were a truly decentralized fallback user dashboard option that 3rd party dashboards had to improve upon to gain traction.

Is there any way we can build and deploy an easy-to-access user dashboard front end without hosting it ourselves? Is there any kind of IPFS solution for this?

2 Likes

I’ve thought about this a bunch since we first discussed it.

I’m convinced now that we should build it and host it ourselves in the manner which is most useful for building the Tribute business, while keeping it open-source and enabling self-hosting. This includes yes tracking site usage, yes tracking IP, yes taking advantage of all breadcrumbs of user data we can collect to gain insight into usage.

Look at examples from two very successful businesses: Bitwarden, and Discourse. If you dig around on their site you will eventually find the options for self-hosting, and they even provide docs/guides/forums to enable this. Bitwarden now has two forks maintained by the community. Discourse has many community-created themes and plugins.

Everyone “gets” this biz model and it makes a lot of sense. I dont think its gonna be looked at negatively by anyone except crypto extremists. We will encourage others to host it besides us, but I don’t anyone will for a while.

If we spend a lot of effort making it decentralized, this doesnt add any value. I dont think it will encourage any more adoption than just a regular non-decentralized dashboard. People want convenience, including the people we will encourage to self-host. A lot of projects like this fail b/c they make their app/widget “too crypto” and dont cater to a wider audience. A regular dashboard (like a docker instance on a standard server) would be much easier to spin -> more people building and hosting new ones.

tl;dr making decentralized will slow us down, and doesnt add value. Making centralized will fuel insight into future products and doesn’t hurt our image if we open-source it.

1 Like

I think it’s far too early to be thinking about monetization. There currently aren’t any expenses since all of the the work is done on testnet and front end. When you start talking about tracking users there will be infrastructure that needs to be built/managed/mantained not to mention server costs. We also have a barely working proof of concept. I think focus should be on just making the software better with some example usages.

im not talking about monetizing right now, im agreeing with you that we should be building speed/ease, not worrying about full decentralization for the user dashboard.

Server costs are $10/month. We already have the dashboard almost built. We can throw in Piwik (open source tracking) and have ourselves a working demo that does everything I had in mind.

I don’t want to risk slowing down our pipeline due to a new decentralized hosting paradigm, but if in fact we can use something that works just as well from both our side and the users’ side without data exposure, I’m still in favor of it for long range strategic and ethical reasons. I agree that right now, no one except for a very tiny group would bat an eye if we were to use the standard hosting model, but what about in two years? The ethics, norms and liability issues around capture of user data are undergoing a sea change, and to me the direction of where the new web is headed is pretty clear.

To move beyond the philosophical and theoretical, what would be the criteria you would need a decentralized hosting solution to meet to be willing to choose it over the status quo option? I’d like to try to find some outside help to build the best version of a decentralized hosting option, so that we aren’t spending our own bandwidth on this issue. We have some time before we need to commit to an initial hosting option.

1 Like

Without tracking, how will we know how many people actually visit our site? Like are we ok with only having blockchain data?

I’m with @pi0neerpat on this one. While you could go through the work of making the whole thing live in decentralandia on IPFS, I don’t think 99% of the people using Tribute would even know or care.

Here’s how I see it:

  • Tribute landing page: explains what Tribute is, how it works, and helps people get widgets to put on their site. Tracking is ok here and probably important to be able to know how well the message is being received.
  • Tribute dashboard: No tracking here, centralized initially but eventually should be decentralized so that the service can continue to operate whether or not you guys continue the Tribute business

As it is decentralized hosting is currently still a pretty big pain and most people still aren’t doing it.

2 Likes

Sounds like the best choice for the project is to use the best current hosting practices and possibly a split landing page/dashboard architecture, with the latter enabling a self-hosting option for power users (or using a decentralized option built by some other team).

1 Like