ANT Token - Price & Trading topic

all nodes reach out for a smart contract to get the current quote - right? and they possibly do the same to check for received payments …

with people running up to 50k nodes behind a singled IP address … is it possible we’re simply hitting rate limits of the public https://arb1.arbitrum.io/rpc <<< arbitrum RPC endpoint with our queries?! … (and the larger the files the more nodes need to create quotes/check TXs …)

and @Josh doesn’t have issues because he’s connecting from out in the woods down there in the US and the variable delays to reach the DC nodes in Europe are huge enough to spread the load a bit and for him the rate limit doesn’t hit that hard …

5 Likes

simple solution: add EVM capability to the network and ditch the external smart contract dependency :slight_smile:

1 Like

I don’t think a team of 10,000 Engineers and 100,000 marketing people could satisfy all of the request for “you must do XX” in this thread as well, but in other threads it seems more realistic “can we think of the implications of XXX”, which is also funny.

10 Likes

that suggestion about developing a AVM ofc was a joke :smiley: just to clarify xD please don’t (yet)

1 Like

I think there is actually, however no point in us blasting horns from the heavens until we sort out some teething issues, particularly the API and upload issues we have. So it’s all an orchestration

18 Likes

It’s good to see you and some others from the team back interacting on the forums more. I can really see and feel some of the struggles and understand most of the decisions you make. (I.e. minimal marketing effort till some things sorted and launching this network to continue to improve in live environment). I think most of the “demands” or requests or speculations could be so “easily” resolved by just every now and then post a message with your finding and what’s being worked on. People here (and especially those on Discord that not all read the topics here) are in the dark on what’s happening.

It doesn’t have to be a long message either, but a simple: “we’re aware of issue a, b and c and are working to fix a and b for the next update which we do not have an eta for yet and then we’ll move on to c if nothing more urgent pops up”.

I know this is most likely the case because i read evrrything and am on here close to every hour I’m awake and even then it’s sometimes difficult reading between the lines and adding it all up to make an educated guess. We have a very engaged community here and I think it would really help everyone to manage expectations (without the need for setting yourself up with deadlines).

Hope this is something the team can consider as I think it would improve a lot of the frustrations the team and the community has been having.

9 Likes

This is where we need to get to, but even this level of detail is hard to get through the in house team. We are trying out some new tools in house for comms between the Engineers. So it’s a large task. Then we have to be careful not to discount every word being torn apart and a zillion more questions. It’s life though.

If you watch some posts you will see the ones with a large amount of likes receive replies that are almost entirely more questions. Folk post replies with maybe 3-5 questions each. so a single announcement such as

Can be published quite easily, I do this quite a bit, but in the more public channels some thing like, say, for example.

We are aware of an issue in uploads and the affect it has on the API, we are working on an issue with relay nodes to help there in terms of connections and also the quoting mechanism for clients, as we see failed quotes are a large driver of upload failures.

That would be replied to with 50-100 questions and 10-20 heavily direct and MST DO THIS opinions :smiley: So it get’s lost in the weeds of a load of replies that often fall into a bit of chaos.

I just mention this as it’s the reality of the theory we can just post a clarifying message. At the same time I am also in agreement we need to post clarifying messages and we try to do that in weekly updates, but that does not seem to be enough, so we need to do it more and in other places or threads or with different words or something. Then folk will point out again we need to just post a simple message of … :smiley: :smiley:

It really is the realty and it’s cool, it’s how it is.

15 Likes

@rusty.spork is the point of contact

Don’t be jealous be happy for me :grin:

7 Likes

i’m very happy for you :smiley: and first tests suggest for price discovery (ant file cost ..) it’s the client who does the work … then the question is … what do nodes do wit the network and why do we even need to pass the network … so they just validate the payment (?) …

4 Likes

I fully understand and I’m glad that we have the same vision as to where we want to be communication-wise. Personally, I would create a topic that is locked that the team can share what issues they’re working on and what is going to be needed before a network update rolls out. Clarify in the opening post that it’s more an “FYI” than an invitation to an open discussion.

We as a community have to understand that the team cannot fall into the trap of endless debates and there is no satisying everyone. I think they’ll get used to it and will appreciate they at least know what’s on the teams mind.

Goodluck the coming days/weeks/months, I’m sure it’s crazy times for you guys so I’ll let you get back to it. :folded_hands:t3::pink_heart:

10 Likes

This is where my mind is at reading all of this. It feels like very much a client issue and somehow a timeout of some sort or not enough waiting time.

3 Likes

but we’re at minutes to fail … so hard to believe it can be waiting time … there must be some dead ends … or there are nodes that are such slow to respond that they should be kicked out of the network …

3 Likes

I dont use that, probably should. So far the fees have been so irrelevant I haven’t been bothered.

2 Likes

Yes, but if some clients work and some don’t is would seem to feel more like a client as opposed to node issue ??
If @Josh is getting good results, it won’t have anything to do with his nodes, it’s his client, of course it could be his masterful coding or in fact using the API in ways the cli has not etc.

It’s interesting for sure.

Are people able to upload from VPS machines with greater success than perhaps slower home nodes? OR perhaps some folk running loads of nodes form home makes the client unhappy?

5 Likes

I think that’s why he needs to share it so others can test it :winking_face_with_tongue:

4 Likes

:rolling_on_the_floor_laughing::sweat_smile::rolling_on_the_floor_laughing::face_with_tears_of_joy: this is a serious place for serious conversation.
But I will frame that comment and use it out of context one day :laughing:


I do want to try the cli today and see if I get different results.

But what I do know for sure is it seems that creating archives which the cli does by default?? takes forever and the network feels so much faster making that step optional.

5 Likes

and we shouldn’t forget josh uses 5 internet connections via 5 routers with separated vpns for the traffic for nodes and his other network stuff all on fibre optic internet … he’s a datacenter :wink: you made me sell a 1 digit amount of ANT to stock up on ETH to make sure it’s not a money issue when testing on a vps

2 Likes

ha! i think i’ll succeed now (maybe :smiley: ) in the previous attempts i got a payment contract error … now i see on the blockchain i’m paying for my chunks and there was probably just some additional headroom for spending needed - uploading since 9 14 minutes now from vps :slight_smile: (file size: 6 byte)

Using what? See my comment above about archives. It took me longer to add the completed 34mb upload to an archive than it took to upload.

I find that all the time.

Point of the story is that uploads are faster than they appear lots of time spent after the upload completes moving the address into an archive.

Then people say uploads are slow, its not exactly true.

1 Like