# RESPONSE TO UPDATE #1 On the first update of this proposal, a list of challenges/issues was reported, below you can find the response for those issues. ## Issue 1: 400-type errors indicative of unauthorized access *After some experimentation and community outreach, adding a User-Agent header fixed the issue. While some consider this best practice, there is no mention of this being necessary in the documentation.* **Answer**: The User-Agent header is not required to retrieve the specified information from the Catalysts nodes. Below there are some examples that poove the point and work as expected, returning the APIs result from any Catalyst node, this CURL commands can be tested with any DAO node and should respond as expected. ``` curl -H "User-Agent: " -v "https://peer.decentraland.org/comms/peers" curl -H "User-Agent: " -v "https://peer.decentraland.org/comms/islands" curl -v "https://peer.decentraland.org/comms/islands" curl -v "https://peer.decentraland.org/comms/peers" ``` We will highly appreciate it if you can provide more context and examples to be able to reproduce this issue in order to update the documentation and/or fix any existing bug if necessary. If a node is not responding as expected, the owner will need to be contacted to check what is going on. ## Issue 2: Several 529 errors (“Too many requests”) *returned as an NGINX HTML page. This error is quite curious as our data was captured from each node at consistent 20-second intervals. This would seem to indicate either misuse of the standard error code (there is a different reason access was withheld), or a policy that declares too many requests across all users of the API. In other words, in the latter case one bad actor can disable data collection for everyone, instead of simply throttling the bad actor.* **Answer**: What's happening? The rate limit is applied at the endpoint level across all requests done due to the processing cost of the endpoint. At the time of the limit configurations, the baseline was the current consumption with an added 30% capacity to prevent affecting any existing client, the result was a limit of 40 req/min between `/comms/islands` and `/comms/peers` and this has been working well until now Why? To protect the nodes a general rate limit will always be needed and IPs can be easily faked, if both rates limit are applied, one per IP and one Global, a bad actor would still be able to deny the service to other users by doing a DDoS. On the other hand, the Foundation nodes are behind Cloudflare, this also presents a challenge to create a canonical rate limit configuring by IP due to how Cloudflare manages the HTTP headers moving the origin IP to a different header. If the mentioned header variable is used for the rate limit configuration, then the rest of the community nodes that are not behind Cloudflare would be affected by this setting. How to work this around? Rate limit increased 5x: 200 req/min On Oct 18th, Catalysts nodes were updated with this new rate limit increase. This new setting should provide enough bandwidth for the proposed use case, this takes into consideration the amount of rate-limited requests quantity and there will be plenty of capacity to respond. Long Term Solution Implement an allow list by an API key that should be requested through a DAO poll with a specified service quota for a specific actor and let the community decide who should have the keys. Rethink how the data is calculated and cached on the server side to avoid unnecessary processing. ## Issue 3: DNS handshake failures *Usually indicative of the node being offline and unable to be found via their url. Given that we trust that these nodes to be up and available for Decentraland users to have a good user experience, it would be good to know details of any SLAs (e.g. uptime requirements) that node operators commit to and to understand who is meeting these conditions.* What's happening? We need to embrace the concept of decentralization not only from an infrastructure but also from a governance perspective. Nowadays the Catalysts servers both hosted by the Decentraland Foundation and the community do not have an SLA in terms of reliability (uptime, latency, error rate, and saturation). We are more than happy to receive proposals on how to implement this improvement opportunity but nowadays there is no guarantee for the node's uptime and if a node is malfunctioning the community members may create a poll to remove it from the DAO network. Currently, this doesn't represent an issue due to the commitment of the catalyst owners and the communication channels available to tackle issues with the nodes. We would love to understand more about the issues you are experiencing related to DNS handshake and discoverability. Why? Having a decentralized network allows some nodes to be offline while providing the same good user experience for the end users. The load balancing and routing algorithms act as a derisk mechanism to guarantee the player experience. Nodes can be offline for some time for several reasons like changing a disk, updating, doing a migration, patching, or even due to an attack. There are ways to avoid this downtime but they are not currently implemented. How to work this around? From the metrics point of view, if the server is not responding, it can be assumed that it won’t have any peers or islands. In these cases, we recommend your team to implement retry with an exponential backoff and jitter logic.

Creation of DAO-Owned Data Aggregation Layer for Decentraland Core This proposal has been ENACTED by a DAO Committee Member (0xfe91c0c482e09600f2d1dbca10fd705bc6de60bc) Vesting Contract Address: 0x6141047169e6df0822b47687a1be516b2bd28d29 [View Transaction](https://etherscan.io/tx/0x5018779b416432d21eddbb657ec43df6b3b97caffd04f01c7648d70daa08a98c)

Creation of DAO-Owned Data Aggregation Layer for Decentraland Core This proposal is now in status: PASSED. Voting Results: * Yes 82% 3,155,832 VP (71 votes) * No 18% 712,823 VP (4 votes)

Based on the reputations of the authors and those who voted in favor of this proposal, I'm voting YES. Admittedly this goes a bit above my head, but I believe the data should be freely accessible and not only accessible to the foundation. I appreciate the in depth explanations from Morris and Maryana. This also helped me to make this decision.

I voted YES on this proposal - The Atlas Corp team, to my knowledge, has been a provider of ad-hoc reports to multiple organizations & individuals in Decentraland for various land KPI metrics - pulling & transforming data from a source that a normal user may not easily be able to access and query. Decentraland users should have the ability to access real-time data to utilize for their independent reporting needs (land activity, understanding total activity in DCL at a given day/place, marketplace data). Personally, I would love to pull data and perform my own analytics over Decentraland’s land activity for education purposes. I’m sure there are a few data analysts in our community who may feel the same. From my perspective, this API database to be created by Atlas Corp will help users access a raw dataset & then transform the data and analyze it for their needs. This can enable data scientists and developers in our community to band together and help create dashboards that may help the broader community understand the current stats of DCL. I would love to see a few members of the community get together & create a focus group to help Atlas with their development of what data points would be most beneficial for this database to make this an efficient dataset, or reducing data points that may not be as crucial. The budget seems reasonable given the scope of this project. As long as the Atlas team is able to access the data, this proposal is needed for decentralized ad-hoc data reporting. I am not familiar with the change in the catalyst infrastructure in place - this might be another proposal or discussion. The other solution is for the community to rely on an organization who has high-level reporting dashboards, reporting on an XXX basis. However, some developers may only need specific parcel data, or drilled down details that may not be reflected into a “basic” report. Just my two cents.... Thanks, Maryana

Currently, at a granularity of 20 second intervals, the data is about 1 gig per day with the current user base. Would prefer to be saving data at 5 second intervals, but that would require a significantly increase in infrastructure costs. This is definitely up for discussion, and its a balance between costs and benefits that can be decided by the community as puts the end points to use. As this data aggregation layer is built out, our team would love feedback from the community about what queries should be supported. The data will be stored raw, with queries built to unpack the data into different useful insights. All of the data will also be available for bulk download, which would allow you to spin up an independent database to build whatever queries you may want. In an ideal world, community developed queries could be added to the protocol.

@MorrisMustang @HowieDoin this got sidestepped in other discussions, but my big question here is if ATLAS starts collecting data and distributing it as the main proxy of the catalyst server infrastructure as a whole, will we still have access to the same granularity of data as we do now in a public way? it sounds like the API you would devise just gives access to relatively basic pre-computed stats, but maybe i have that wrong.

Lol when 2 people can pass the proposal. Joke ass vp system. give these boys the money collect that data.

not gonna lie a lot of this goes over my head but @MorrisMustang and @HowieDoin have been amazing to the Decentraland Community and I have confidence they will execute this properly, so this is an easy YES vote from me!

so maybe first proposal should be to stop that endpoint from being deprecated - maybe these could be combined though, or if the DAO takes over handling stats in an opensource way that would also be fine - but yeah, i agree, just losing access to that data with almost no warning is pretty lame

So much for users being in control of their data. This completely unacceptable and not in line with the mission they are projecting, nor were the key players who make use of that data consulted in this process. A major misstep by the catalyst team. Disenfranchising developers who have worked hard on platform developments is not the way. The Foundation team should not be deprecating that end point. Closing that end point is an attempt to control the data that should be open, and should be rejected by the community. 

but from my understanding it's kind of already happening - see the catalyst channel in the main dcl server

That would be the second time the Foundation has recommended removing that endpoint, to which the community needs to say NO. Initially the discussion was around the burden that end point puts on the servers. This is the precise reason for this proposal. That endpoint needs to be saved, so developers can access that data from a cached layer, that can be scaled to meet the needs of app developers, without causing conflict for those in world. The Foundation does not explicitly have control of the road map as it relates to the Decentraland protocols, which includes the content server and its API. That API endpoint is what has made it possible for us to do the work we do in Decentraland for the last 18 months. Removing that end point means the data is now no longer open and accessible. It would then only be available to the Foundation, as they are able to gather directly from the client.

In general I think this a great idea, but isn't the /comms/islands endpoint being deprecated in a few weeks as part of changes to the infrastructure?