Community Poll: Socket Server for Real-Time Data

Hi there, everyone! Things are moving quickly, and the team has a question.


  • The state management of is being reworked, as well as the look and feel.
  • We’ve been listening to suggestions for the new design.
  • Many requests revolve around a desire for real-time data.
  • A good solution for quickly retrieving data is to utilize a proxy server to query data and store it, then passing that data to subscribers.


  • Ideally, decentralized applications shouldn’t rely on external servers.
  • Using external servers brings the risk of potentially being compromised.
  • Users in the space may have a general aversion to external servers.


  • The external server would only be used to retrieve data, not to write to the blockchain.
  • The client would not transmit any undisclosed metrics to the external server.
  • Both the front end and the external server’s code would be 100% open-source and annotated with TSDOC.
  • There can be an opt-in setting in the Settings page that switches between real-time/external server and local polling.


  • Instead of using an external server, the server could be distributed and downloaded optionally so as to receive faster data.
  • Avoid any use of a proxy server and continue polling for data locally, foregoing real-time data.
Community Poll: On Using External Socket Servers
  • I’m comfortable with whatever solution the team deems best.
  • I’m comfortable with a socket server that is fully open source and verified.
  • I’m comfortable with an optional connection to a socket server, either via opt-in or download.
  • I’m not comfortable with a socket server under any circumstances.

0 voters


Hello! I want to make sure I’m understanding this correctly: Would the “optional connection to a socket server…” option be optimal for everyone? People who want real time data get access to it but the traditional “polling locally” would still be on the website?

Would this increase costs enough to be a hinderance?


The cost increase would be negligible. The socket server isn’t particularly hard to write, and would be relatively small.

I do agree that the optional connection is the ideal approach, and is the one I am lobbying for. I’m looking forward to additional responses.


If someone is paranoid about the data presented on the website they can check data on-chain using available tools. Solution should be easiest and fastest to implement.

Getting into “I don’t trust this server data” is a slippy slope. Next thing will be “I don’t trust the hosting”, “I don’t trust the DNS resolver for” … how do these technical projects drive user adoption? To NDX value?

If you are looking for stuff to work on- I am waiting patiently for the ability to vote on governance proposals of tokens inside an index. This is a major value prop of NDX and should be a top priority.

At this stage, the core team is in change, it’s nice that we are being asked about our opinion, I still belive it’s the core team decision.

How about querying data using subgraphs (i.e. via The Graph protocol)? I guess this might incur certain overheads (e.g. development cost for the subgraph) which makes this option somewhat less attractive.

We’re already doing this :smiley:

What I want to do is run a proxy server to make these requests, and then cache those to reduce time-to-data for consumers.

1 Like

I said whatever the team deems best but personally I always tend towards being pro optionality.

Ah I see, I get what you mean now. In this case, you have my full support in using a proxy server. As you’ve mentioned the server would not be writing data to the blockchain, I guess the chance of exploit is very low.