Did a quick dive to explore viability of migrating to ipinfo. My idea was: use lite version for enriching everything and then use pay-as-you-go for enriching authenticated user sessions.
I couldn't get /lite/ to work. In a sample of IPs I've tried with, multiple are returning 404. Your website for the same IPs is returning information. Looks like these are just not included in the lite dataset?
Turns out there is no pay-as-you-go tier. Subscription is the only option. Not a deal breaker, but dissapointing setup.
Do you happen to know if anyone is compiling all of this data about VPNs into one place? It would be super interesting to know which VPNs are providing genuine services vs masquerading the locations. Maybe even an SEO for you.
> I highly recommend that you work with current day's data.
Just to clarify: You are suggesting that we don't pro-actively enrich every IP address, store IPs, and only enrich them when troubleshooting something?
So many of my open questions answered in one answer. Thank you.
A follow up based on new information - if 'geofeed' identifies something with wrong geo location, and your method detects different geolocation, what do I see as the consumer consuming your API? I am assuming the inferred data, but that also feels counter-intuitive (since the data does not align with what ASN/ISP are reporting).
How often does your active measurement data disagree with geofeed data?
How do you handle mobile/cellular IPs
> Do you really need large scale IP address enrichment of all the IP addresses that visit your website? If yes, then for the first layer use our free data that provides ASN and country information.
If I am troubleshooting a support case that is days/weeks/months old, wouldn't this mean that enriching this information at a later date may give me different data than what it was associated with at the time the requests were made? My understanding was that IPs get re-assigned.
How frequently do IP-to-location mappings change in practice?
This should not add more latency than your average VPN, since the overhead of websocket is minimal and roundtrip time is about the same.
At the moment, this is running on a single-instance with no load-balancing. The intended use case was to enable streaming of MCP SSE traffic, which is very lightweight. I would expect this to be able to handle a lot of traffic just like that, but if people start using the public instance for other use cases, I will need to think of ways to scale it.
The current implementation is HTTP-focused as that was the primary use case. TCP tunneling is possible architecturally but not something I've had in mind. I suggest start by raising an issue on GitHub and adding thumbs up. If it receives enough attention, I will prioritize it. I am less familiar with what would supporting UDP entail, so cannot answer that right now.