CoreWeave just launched their own AI Object Storage. Our take? We love to see it.
At first glance, it might look like a competitive offering, but as far as we’re concerned, the more storage options out there, the better for builders. It’s another sign that object storage has officially arrived as a key ingredient in the AI stack.
Now, your AI stack can look like this: Fast, flexible storage close to your GPUs from CoreWeave (essential for training and inference). And when the run’s over? Move it to Backblaze B2 Overdrive to keep it ready for your next run at the right temperature and price-to-performance ratio.
More options mean more ways to build smart, cost-efficient pipelines that let teams train faster and iterate more without getting locked in. We’ll always cheer for that.
Why object storage is essential for AI workloads
How do you balance scalability with performance while staying on budget? This ebook explores how object storage enhances every stage of the pipeline from collection to training to deployment, and provides real-world use cases.
Why object storage matters in the AI stack
Every AI model depends on moving massive datasets through training, inference, and retraining cycles. Each stage requires fast, reliable access to data. That’s where object storage comes in.
Object storage enables this by offering:
Elastic scalability for petabyte-scale data.
Reliability and durability across long model lifecycles.
Lifecycle management features to balance cost, performance, and accessibility.
As AI projects scale, smart data management becomes just as important as GPU performance. High-end GPUs can only deliver full value when they’re continuously fed the right data at the right time. When data sits in the wrong tier or takes too long to retrieve, compute resources go underused. And that means wasted time and money.
Balancing performance and cost in AI workloads
CoreWeave’s Local Object Transport Accelerator (LOTA) delivers up to 7GB/s throughput per GPU, helping data move quickly between storage and compute. With pricing around $110 per terabyte (about $60 with discounts) and regional capacity up to 10TiB, it’s built for performance-critical workloads where proximity to GPUs makes a measurable difference.
Its launch adds more choice to the ecosystem and highlights the growing demand for storage built specifically for AI. As more specialized options emerge, organizations are thinking carefully about how to right-size their infrastructure for each stage of the AI lifecycle.
When maximum performance is the goal, GPU-adjacent storage like CoreWeave’s can help teams squeeze out every last bit of speed during intensive training cycles. But for most AI workloads, B2 Overdrive provides the right balance of cost and performance. It offers the throughput and durability needed to support active training while keeping pricing predictable and scalable.
Many AI builders combine these strengths through a multi-cloud setup. Teams might use CoreWeave Object Storage when latency and proximity to GPUs deliver measurable gains, and then keep the rest of their AI pipeline on B2 Overdrive so datasets remain readily available for retraining, testing, or deployment.
Example configuration:
CoreWeave Object Storage for specialized, compute-intensive training where every millisecond counts. It’s ideal for short bursts of high-throughput processing, such as large-scale model fine-tuning or time-sensitive inferencing.
B2 Overdrive for the broader AI workflow, including day-to-day training, staging, versioning, and long-term dataset management. It provides the performance needed for ongoing model development while keeping data costs predictable and accessible across teams and environments.
B2 Overdrive offers:
Storage at roughly $15 per terabyte
High throughput and rapid access for post-training workflows
Simple APIs and event notifications to automate data movement across environments
This kind of architecture gives teams the freedom to use each platform where it shines. Backblaze handles the heavy lifting for most workloads, while CoreWeave adds targeted acceleration when raw GPU performance is the top priority. The result is a flexible, cost-aware workflow that supports both innovation and scale.
AI infrastructure that plays to every strength
The most effective AI setups use the right cloud for the right job. They run training where GPUs can perform at their peak, and store data where it stays organized and ready to move when needed.
B2 Overdrive provides a foundation for this strategy, offering a layer of object storage that keeps data secure, accessible, and easy to integrate across environments. Teams can combine each platform’s strengths to achieve speed when it’s needed, scalability that endures, and freedom from lock-in and runaway costs.
The AI ecosystem is expanding, and with the right partners, so are the possibilities.
Here at Cloudflare, we’ve been celebrating Halloween with some zombie hunting of our own. The zombies we’d like to remove are those that disrupt the core framework responsible for how the Internet routes traffic: BGP (Border Gateway Protocol).
A BGP zombie is a silly name for a route that has become stuck in the Internet’s Default-Free Zone (aka the DFZ: the collection of all internet routers that do not require a default route, potentially due to a missed or lost prefix withdrawal).
The underlying root cause of a zombie could be multiple things, spanning from buggy software in routers or just general route processing slowness. It’s when a BGP prefix is meant to be gone from the Internet, but for one reason or another it becomes a member of the undead and hangs around for some period of time.
The longer these zombies linger, the more they create operational impact and become a real headache for network operators. Zombies can lead packets astray, either by trapping them inside of route loops or by causing them to take an excessively scenic route. Today, we’d like to celebrate Halloween by covering how BGP zombies form and how we can lessen the likelihood that they wreak havoc on Internet traffic.
Path hunting
To understand the slowness that can often lead to BGP zombies, we need to talk about path hunting. Path hunting occurs when routers running BGP exhaustively search for the best path to a prefix as determined by Longest Prefix Matching (LPM) and BGP routing attributes like path length and local preference. This becomes relevant in our observations of exactly how routes become stuck, for how long they become stuck, and how visible they are on the Internet.
For example, path hunting happens when a more-specific BGP prefix is withdrawn from the global routing table, and networks need to fallback to a less-specific BGP advertisement. In this example, we use 2001:db8::/48 for the more-specific BGP announcement and 2001:db8::/32 for the less-specific prefix. When the /48 is withdrawn by the originating Autonomous System (AS), BGP routers have to recognize that route as missing and begin routing traffic to IPs such as 2001:db8::1 via the 2001:db8::/32 route, which still remains while the prefix 2001:db8::/48 is gone.
Let’s see what this could look like in action with a few diagrams.
Diagram 1: Active 2001:db8::/48 route
In this initial state, 2001:db8::/48 is used actively for traffic forwarding, which all flows through AS13335 on the way to AS64511. In this case, AS64511 would be a BYOIP customer of Cloudflare. AS64511 also announces a backup route to another Internet Service Provider (ISP), AS64510, but this route is not active even in AS64510’s routing table for forwarding to 2001:db8::1 because 2001:db8::/48 is a longer prefix match when compared to 2001:db8::/32.
Things get more interesting when AS64510 signals for 2001:db8::/48 to be withdrawn by Cloudflare (AS13335), perhaps because a DDoS attack is over and the customer opts to use Cloudflare only when they are actively under attack.
When the customer signals to Cloudflare (via BGP Control or API call) to withdraw the 2001:db8::/48 announcement, all BGP routers have to converge upon this update, which involves path hunting. AS13335 sends a BGP withdrawal message for 2001:db8::/48 to its directly-connected BGP neighbors. While the news of withdrawal may travel quickly from AS13335 to the other networks, news may travel more quickly to some of the neighbors than others. This means that until everyone has received and processed the withdrawal, networks may try routing through one another to reach the 2001:db8::/48 prefix – even after AS13335 has withdrawn it.
Diagram 2: 2001:db8::/48 route withdrawn via AS13335
Imagine AS64501 is a little slower than the rest – perhaps due to using older hardware, hardware being overloaded, a software bug, specific configuration settings, poor luck, or some other factor – and still has not processed the withdrawal of the /48. This in itself could be a BGP zombie, since the route is stuck for a small period. Our pings toward 2001:db8::1 are never able to actually reach AS64511, because AS13335 knows the /48 is meant to be withdrawn, but some routers carrying a full table have not yet converged upon that result.
The length of time spent path hunting is amplified by something called the Minimum Route Advertisement Interval (MRAI). The MRAI specifies the minimum amount of time between BGP advertisement messages from a BGP router, meaning it introduces a purposeful number of seconds of delay between each BGP advertisement update. RFC4271 recommends an MRAI value of 30-seconds for eBGP updates, and while this can cut down on the chattiness of BGP, or even potential oscillation of updates, it also makes path hunting take longer.
At the next cycle of path hunting, even AS64501, which was previously still pointing toward a nonexistent /48 route from AS13335, should find the /32 advertisement is all that is left toward 2001:db8::1. Once it has done so, the traffic flow will become the following:
Diagram 3: Routing fallback to 2001:db8::/32 and 2001:db8::/48 is gone from DFZ
This would mean BGP path hunting is over, and the Internet has realized that the 2001:db8::/32 is the best route available toward 2001:db8::1, and that 2001:db8::/48 is really gone. While in this example we’ve purposely made path hunting only last two cycles, in reality it can be far more, especially with how highly connected AS13335 is to thousands of peer networks and Tier-1’s globally.
Now that we’ve discussed BGP path hunting and how it works, you can probably already see how a BGP zombie outbreak can begin and how routing tables can become stuck for a lengthy period of time. Excessive BGP path hunting for a previously-known more-specific prefix can be an early indicator that a zombie could follow.
Spawning a zombie
Zombies have captured our attention more recently as they were noticed by some of our customers leveraging Bring-Your-Own-IP (BYOIP) on-demand advertisement for Magic Transit. BYOIP may be configured in two modes: “always-on”, in which a prefix is continuously announced, or “on-demand”, where a prefix is announced only when a customer chooses to. For some on-demand customers, announcement and withdrawal cycles may be a more frequent occurrence, which can lead to an increase in BGP zombies.
With that in mind and also knowing how path hunting works, let’s spawn our own zombie onto the Internet. To do so, we’ll take a spare block of IPv4 and IPv6 and announce them like so:
Once the routes are announced and stable, we’ll then proceed to withdraw the more specific routes advertised via Cloudflare globally. With a few quick clicks, we’ve successfully re-animated the dead.
Variant A: Ghoulish Gateways
One place zombies commonly occur is between upstream ISPs. When one router in a given ISP’s network is a little slower to update, routes can become stuck.
Take, for example, the following loop we observed between two of our upstream partners:
Simultaneously, zombies can occur entirely within a given network. When a route is withdrawn from Cloudflare’s network, each device in our network must individually begin the process of withdrawing the route. While this is generally a smooth process, things can still become stuck.
Take, for instance, a situation where one router inside of our network has not yet fully processed the withdrawal. Connectivity partners will continue routing traffic towards that router (as they have not yet received the withdrawal) while no host remains behind the router which is capable of actually processing the traffic. The result is an internal-only looping path:
Unlike most fictionally-depicted hoards of the walking dead, our highly-visible zombie has a limited lifetime in most major networks – in this instance, only around around 6 minutes, after which most had re-converged around the less-specific as the best path. Sadly, this is on the shorter side – in some cases, we have seen long-lived zombies cause reachability issues for more than 10 minutes. It’s safe to say this is longer than most network operators would expect BGP convergence to take in a normal situation.
But, you may ask – is this the excessive path hunting we talked about earlier, or a BGP zombie? Really, it depends on the expectation and tolerance around how long BGP convergence should take to process the prefix withdrawal. In any case, even over 30 minutes after our withdrawal of our more-specific prefix, we are able to see zombie routes in the route-views public collectors easily:
You might argue that six to eleven minutes (or more) is a reasonable time for worst-case BGP convergence in the Tier-1 network layer, though that itself seems like a stretch. Even setting that aside, our data shows that very real BGP zombies exist in the global routing table, and they will negatively impact traffic. Curiously, we observed the path hunting delay is worse on IPv4, with the longest observed IPv6 impact in major (Tier-1) networks being just over 4 minutes. One could speculate this is in part due to the much higher number of IPv4 prefixes in the Internet global routing table than the IPv6 global table, and how BGP speakers handle them separately.
Source: RIPEstat’s BGPlay
Part of the delay appears to originate from how interconnected AS13335 is; being heavily peered with a large portion of the Internet increases the likelihood of a route becoming stuck in a given location. Given that, perhaps a zombie would be shorter-lived if we operated in the opposite direction: announcing a less-specific persistently to 13335 and announcing more specifics via our local ISP during normal operation. Since the withdrawal will come from what is likely a less well-peered network, the time-to-convergence may be shorter:
Indeed, as predicted, we still get a stuck route, and it only lives for around 20 seconds in the Tier-1 network layer:
19. be12488.ccr42.ams03.atlas.cogentco.com
20. 38.88.214.142
21. be2020.ccr41.ams03.atlas.cogentco.com
22. 38.88.214.142
23. (waiting for reply)
24. 38.88.214.142
25. (waiting for reply)
26. 38.88.214.142
Unfortunately, that 20 seconds is still an impactful 20 seconds – while better, it’s not where we want to be. The exact length of time will depend on the native ISP networks one is connected with, and it could certainly ease into the minutes worth of stuck routing.
In both cases, the initial time-to-announce yielded no loss, nor was a zombie created, as both paths remained valid for the entirety of their initial lifetime. Zombies were only created when a more specific prefix was fully withdrawn. A newly-announced route is not subject to path hunting in the same way a withdrawn more-specific route is. As they say, good (new) news travels fast.
Lessening the zombie outbreak
Our findings lead us to believe that the withdrawal of a more-specific prefix may lead to zombies running rampant for longer periods of time. Because of this, we are exploring some improvements that make the consequences of BGP zombie routing less impactful for our customers relying on our on-demand BGP functionality.
For the traffic that does reach Cloudflare with stuck routes, we will introduce some BGP traffic forwarding improvements internally that allow for a more graceful withdrawal of traffic, even if routes are erroneously pointing toward us. In many ways, this will closely resemble the BGP well-known no-export community’s functionality from our servers running BGP. This means even if we receive traffic from external parties due to stuck routing, we will still have the opportunity to deliver traffic to our far-end customers over a tunneled connection or via a Cloudflare Network Interconnect (CNI). We look forward to reporting back the positive impact after making this improvement for a more graceful draining of traffic by default.
For the traffic that does not reach Cloudflare’s edge, and instead loops between network providers, we need to use a different approach. Since we know more-specific to less-specific prefix routing fallback is more prone to BGP zombie outbreak, we are encouraging customers to instead use a multi-step draining process when they want traffic drained from the Cloudflare edge for an on-demand prefix without introducing route loops or blackhole events. The draining process when removing traffic for a BYOIP prefix from Cloudflare should look like this:
The customer is already announcing an example prefix from Cloudflare, ex. 198.18.0.0/24
The customer begins natively announcing the prefix 198.18.0.0/24 (i.e. the same-length as the prefix they are advertising via Cloudflare) from their network to the Internet Service Providers that they wish to fail over traffic to.
After a few minutes, the customer signals BGP withdrawal from Cloudflare for the 198.18.0.0/24 prefix.
The result is a clean cut over: impactful zombies are avoided because the same-length prefix (198.18.0.0/24) remains in the global routing table. Excessive path hunting is avoided because instead of routers needing to aggressively seek out a missing more-specific prefix match, they can fallback to the same-length announcement that persists in the routing table from the natively-originated path to the customer’s network.
Source: RIPEstat’s BGPlay
What next?
We are going to continue to refine our methods of measuring BGP zombies, so you can look forward to more insights in the future. There is also work from others in the community around zombie measurement that is interesting and producing useful data. In terms of combatting the software bugs around BGP zombie creation, routing vendors should implement RFC9687, the BGP SendHoldTimer. The general idea is that a local router can detect via the SendHoldTimer if the far-end router stops processing BGP messages unexpectedly, which lowers the possibility of zombies becoming stuck for long periods of time.
In addition, it’s worth keeping in mind our observations made in this post about more-specific prefix announcements and excessive path hunting. If as a network operator you rely on more-specific BGP prefix announcements for failover, or for traffic engineering, you need to be aware that routes could become stuck for a longer period of time before full BGP convergence occurs.
If you’re interested in problems like BGP zombies, consider coming to work at Cloudflare or applying for an internship. Together we can help build a better Internet!
WhatsApp is one of the most widely used messaging platforms globally, making it an ideal
channel for customer engagement. Whether you’re building a virtual assistant, a customer AI assistant, or an internal communication tool, developing a WhatsApp AI assistant presents unique design and operational challenges.
In this post, we explore best practices for building a WhatsApp AI assistant using AWS services—with a focus on how the AWS Summit Assistant used AWS End User Messaging and Amazon Bedrock to power a responsive, secure, and scalable generative AI assistant.
Why build a WhatsApp AI assistant with AWS End User Messaging
AWS offers a comprehensive set of services that can seamlessly handle the full lifecycle of a WhatsApp interaction—from ingesting and validating inbound messages, storing session context, generating AI responses, to monitoring key performance indicators in real time.
AWS End User Messaging provides native integration with WhatsApp, so you can send and receive messages directly using a REST API or SDK. It also supports AWS Identity and Access Management (IAM), enabling fine-grained control over access, authentication, and user roles.
The following sections outline best practices for designing, building, and operating WhatsApp AI assistants on AWS. Although not every recommendation will apply to every use case, they are based on real-world lessons learned from production deployments like the AWS Summit Assistant.
Use a modular, event-driven architecture
Rather than relying on tightly coupled services or monolithic workflows, design your WhatsApp AI assistant as a set of loosely coupled, modular components. AWS services such as Amazon Simple Notification Service (Amazon SNS), Amazon Simple Queue Service (Amazon SQS), and AWS Lambda are ideal for building scalable, event-driven systems.
By default, AWS End User Messaging publishes inbound WhatsApp messages and engagement events to an SNS topic. To manage throughput and avoid overwhelming downstream components, subscribe an SQS queue to this topic. With this setup, you can process messages at a controlled pace and buffer traffic during bursts.
Depending on your use case, you might choose to skip dead-letter queues (DLQs) in favor of logging failures to Amazon CloudWatch Logs, especially given the real-time nature of chatbots where retrying a failed message hours later might no longer be relevant. Instead, the AI assistant should respond to the user immediately, explaining the issue and suggesting corrective actions such as rephrasing their question or trying again later.
A typical modular structure might have the following components:
SQS queue – An SQS queue subscribed to the WhatsApp Messages & Events SNS topic to control throughput and isolate retries.
A messages processor function for inbound processing and audio processing (optional) – This AWS Lambda function handles initial validation and message-type filtering and transcribes the voice message. The output is published to the Processed messages SNS topic.
Fan-out to downstream consumers – Other Lambda functions through Amazon SQS subscribe to the Processed messages SNS topic to handle specialized tasks like response generation using Amazon Bedrock or categorization and analytics’ purposes.
The following diagram illustrates the solution architecture.
This fan-out architecture promotes clean separation of concerns, avoids redundant processing, and makes it straightforward to introduce new capabilities such as sentiment analysis or content moderation by simply adding new subscribers. By decoupling components and using Amazon SNS and Amazon SQS patterns, each part of the system can scale independently and recover gracefully from localized failures.
Design for controlled processing throughput
When integrating with other AWS services such as Amazon Bedrock, with soft service quotas, it’s critical to manage throughput carefully. Use Amazon SQS to decouple the SNS topic from Lambda invocations. This makes sure spikes in message volume don’t result in throttling or failed invocations. It also lets you scale consumer Lambda functions based on queue depth, allowing for burst handling without dropping messages. In cases where message failure is unrecoverable (such as invalid content or unsupported message types), log the error and notify the user with a helpful message rather than retrying. This keeps the user informed and prevents queues from growing unnecessarily due to retry cycles. This design pattern of Amazon SNS to Amazon SQS to Lambda is foundational for building resilient, scalable AI assistants that meet user expectations for speed and reliability.
Handle voice messages with Amazon Transcribe or Whisper
WhatsApp voice messages are received in OGG format. To process these messages, you can use the AWS End User Messaging GetWhatsAppMessageMedia API to retrieve media files, including audio, images, and video. The audio needs to be converted to a compatible format for transcription: PCM for Amazon Transcribe or WAV for Hugging Face Whisper (available through Amazon Bedrock Marketplace). This conversion can be achieved using a library like FFmpeg, implemented as a Lambda layer.
The processing flow involves fetching audio from WhatsApp, which is then automatically stored in Amazon Simple Storage Service (Amazon S3) in a bucket you create and own (this is the default behavior of the GetWhatsAppMessageMedia API). Next, the audio is converted to the required format and stored locally in Lambda for faster processing before being transcribed.
As a best practice, consider deleting audio files after processing to simplify data management and reduce storage requirements for personally identifiable information (PII). This approach facilitates efficient handling and transcription of WhatsApp voice messages while maintaining data privacy standards.
Enforce strict message validation
To promote quality and security, implement layered validation within your message processing Lambda function. This might differ depending your use case and requirements:
Message status indicators – Mark inbound messages as read and indicate you are responding to maintain the recipients’ interest while generating a response. WhatsApp’s API allows marking messages as read by message ID and setting the typing indicator to true. The typing indicator automatically dismisses after 25 seconds without a reply.
Message type validation – Filter by message type using the inbound WhatsApp message payload’s type field. Implement checks based on your AI assistant’s supported message types and provide static responses for unsupported formats. For example, a text only AI assistant shouldn’t process message types such as Media, Reaction, Template, Location, Contacts or Interactive.
Size limit protection – Add message size validation based on character count. This prevents resource drainage from potential bad actors who might attempt to send extremely large text chunks that could generate excessive large language model (LLM) input tokens.
Conversation management – Track message counts and total character length per conversation, resetting the context when necessary to manage costs and prevent resource drainage. Implement this using Amazon DynamoDB with the recipient’s hashed phone number as the primary key.
Processing lock mechanism – Prevent duplicate processing by implementing a flag system in DynamoDB. When processing a message, set the recipient’s flag to true. While active, new messages receive a static response indicating that a previous message is being processed, avoiding out-of-sync responses and resource waste.
Access control – Consider implementing an allow list for beta functionality or controlled access. This provides selective AI assistant activation for testing while restricting general audience access when needed.
Error handling – Manage response generation failures with clear, static replies to the customer. Include troubleshooting steps or alternative contact channels based on the issue’s severity to maintain a positive user experience.
Security
Consider the following security best practices for message processing systems:
Encryption standards – Encrypt SNS topics, SQS queues, and DynamoDB tables using AWS Key Management Service (AWS KMS) service managed keys or customer managed keys (CMKs) to facilitate data protection at rest and in transit.
PII data protection – For analytics and troubleshooting purposes, avoid logging raw phone numbers when the full number isn’t required. Instead, implement hashing of phone numbers before logging to maintain user privacy while preserving tracking capabilities.
Data retention management – Enable Time-To-Live (TTL) attributes on DynamoDB tables to automatically purge old session data, maintaining data hygiene and avoiding storing PII data when not needed.
Content safety controls – Implement Amazon Bedrock Guardrails to prevent processing or generating unwanted content and messages. When required, use the data loss protection features of Amazon Bedrock Guardrails to safeguard sensitive information.
Use Amazon Bedrock for generative responses and categorization
The AWS Summit Assistant used two key Amazon Bedrock capabilities:
Amazon Bedrock Knowledge Bases – Powered by Amazon Bedrock Knowledge Bases using OpenSearch vector embeddings and Anthropic on Amazon Bedrock, the AI assistant could answer user questions using publicly available event data.
Categorization – Using the InvokeModel API, inbound messages were tagged with categories for analytics. A DynamoDB table stored category counts, enabling trend detection across users.
Sessions persisted using the Amazon Bedrock native session ID feature for consistent conversation flow.
Monitoring
Consider the following monitoring and data analysis options:
Message status tracking – WhatsApp provides six distinct events per message. Though valuable, these should be complemented with AWS service operational metrics for comprehensive monitoring. These events are published on the WhatsApp SNS topic in your AWS account.
Real-time monitoring with CloudWatch – Set up CloudWatch alarms to track SNS message publication rates, providing real-time visibility into WhatsApp activity for both inbound and outbound messages. Extend monitoring to include Lambda function and Amazon Bedrock metrics. For tracking WhatsApp’s six message states, implement a dedicated Lambda function that subscribes to the WhatsApp SNS topic and records each event as a custom CloudWatch metric.
Detailed analysis with CloudWatch Logs Insights – Use CloudWatch Logs Insights for granular monitoring with minimal development overhead. This approach enables advanced queries for metrics not available through standard CloudWatch metrics, such as unique conversation counts and user engagement statistics. The logs’ content depends on your requirements.
Advanced analytics integration – For sophisticated use cases, implement a data pipeline using Amazon Data Firehose to store events in Amazon S3, then visualize using business intelligence tools like Amazon Quick Sight for custom dashboards. For a reference implementation, refer to the following GitHub repo.
Example use case: AWS Summit Assistant
Deployed at AWS Summit Dubai 2025, AWS Summit Johannesburg 2025, AWS Cloud Day Türkiye, AWS Cloud Day Riyadh and re:Inforce re:Cap London 2025, this WhatsApp AI assistant performed the following functions:
Used Amazon Bedrock Knowledge Bases to answer attendee questions
Transcribed voice messages using Whisper
Categorized questions for trend reporting
Operated with near real-time responsiveness using Amazon SNS, Amazon SQS, and Lambda
The AI assistant processed over 2,000 questions with no service interruptions, showing the viability of serverless architecture for WhatsApp-based assistants.
Conclusion
Building a scalable and secure WhatsApp AI assistant with AWS offers numerous advantages for businesses looking to enhance customer engagement. By using AWS services like AWS End User Messaging, Amazon Bedrock, Lambda, and DynamoDB, builders can create robust, AI-powered assistants that handle high message volumes while maintaining security and performance. Key takeaways include:
Adopting a modular, event-driven architecture for flexibility and scalability
Implementing thorough message validation and security measures
Using Amazon Bedrock for advanced Gen AI capabilities
Establishing comprehensive monitoring and analytics
Although these practices provide a strong foundation, they represent just a subset of possible best practices. As WhatsApp and AWS services grow and industry standards change, best practices continue to evolve. Stay current by regularly reviewing AWS documentation and keeping up with new feature releases.
Въздишките на облекчение, които се чуват, идват откъм Министерския съвет. Вече не е необходимо правителството да прави постановки, че има план за действие, за да предотврати дефицит и спекула с горива в България заради санкциите върху „Лукойл“. Те бяха наложени от американската Служба за контрол на чуждестранните активи (OFAC) на две от най-големите руски компании – държавната „Роснефт“ и частната „Лукойл“, и влизат в сила на 21 ноември. Причината е, че руските енергийни компании са основен източник за финансиране на войната, която Русия започна в Украйна през 2022 г. и не желае да спре.
В очакване на решението
Сега на българското и на други европейски правителства, като тези на Нидерландия и Румъния, където „Лукойл“ има собственост, им остава само да чакат дали ΟFAC ще издаде разрешение за сделка, или по-скоро за обвързващото споразумение, между кипърската Gunvor Group Ltd. и дъщерната компания на „Лукойл“ – LUKOIL International GmbH, регистрирана във Виена, която притежава задграничните ѝ активи. Защото кипърското дружество със седалище в Женева подаде оферта да ги купи и руската компания веднага я прие и няма да преговаря с други потенциални кандидати.
„Лукойл“ най-напред съобщи, че продава задграничните си активи. Три дни по-късно дойде и новината за купувача с изявление от руската компания, че „ключово важните условия на сделката са били предварително договорени от страните“.
Не става ясна цената – прогнозите се движат от над 9 до 12–15 млрд. долара, което надхвърля повече от два пъти собствения капитал на Gunvor. Но колкото и да получи „Лукойл“, те ще останат блокирани в специална ескроу сметка, докато не бъдат вдигнати санкциите. Може да се наложи купувачът и продавачът да поискат от ΟFAC да удължи срока за влизане на санкциите в сила, за да осигурят непрекъсната дейност и банкови услуги по време на процеса по приключване на сделката.
В обхвата на чуждестранните активи на „Лукойл“ попада и рафинерията в България – най-голямата на Балканите, чийто капацитет е за преработка на над 196 000 тона барела на ден, – също и над 220 бензиностанции, складове за горива, тръбопроводи, терминали в София, Варна, Пловдив, Стара Загора, Враца и още логистична инфраструктура. Друго дружество на „Лукойл“ в България отговаря за т.нар. бункеровка – доставки и зареждане на горива за кораби в черноморските пристанища, а още едно – за авиационно гориво, обслужвайки летищата в София, Варна и Бургас.
„Лукойл“ има господстващо положение на пазара на горива на едро в България и този дял не може да бъде компенсиран с внос, ако рафинерията спре работа. А причината е, че съседни държави също ще се нуждаят от внос на горива, тъй като и румънската рафинерия на „Лукойл“ ще спре. Предприятието в Плоещ (Petrotel Lukoil) e с четирикратно по-малък капацитет от българското.
Надеждите да не бъде разтърсен пазарът на горива, а с това да се повиши инфлацията, са в законовото задължение за 90-дневен запас от горива за всички страни в ЕС. Остава и да са налични. Управляващите през ден уверяват, че горива ще има до Нова година, а и след това.
Сърбия след 25 ноември?
Но и сръбският президент Александър Вучич преди седмици уверяваше в същото гражданите на Сърбия, обезпокоени заради санкциите, наложени на Naftna Industrija Srbije (NIS), в която мажоритарен акционер е руската „Газпром“ (NIS е и операторът на рафинерията в Панчево):
До Нова година няма да има проблеми с доставките на горива. Имаме достатъчно количества – бензин, дизел, мазут – резервите ни са пълни, няма къде да съхраняваме повече.
Реалността се оказа по-различна. По бензиностанциите от веригата ΝΙS се стигна до хаос заради невъзможността да се плати с карта, а ритмичното снабдяване с горива изглежда застрашено. „Единствената петролна рафинерия в Сърбия ще продължи да работи само до 25 ноември, ако не бъдат осигурени нови доставки на суров петрол, преустановени заради американските санкции“, съобщи агенция „Танюг“, цитирайки енергийната министърка на Сърбия.
Никой обаче не се наема да коментира какво ще се случи, ако дотогава ΟFAC не разреши сделката. Или пък ако не я разреши изобщо заедно с други приложими лицензи и разрешения в съответните юрисдикции.
Министерството на финансите на САЩ вече издаде временен лиценз, който освобождава германския бизнес на „Роснефт“ от санкции до април 2026 г. Берлин разглежда вариантите за изземване на активите на санкционираната компания и продажбата им на чуждестранен инвеститор. „Роснефт“ притежава контролен дял в ключовата рафинерия „Швет“, която осигурява по-голямата част от горивото за Берлин и Източна Германия, включително за летището и химическата индустрия. Компанията е акционер и в рафинериите MiRo и Bayernoil, но не държи контролен пакет, затова те не попадат под санкции.
Как удрят геополитическите бури
Вървят и предположения, че продажбата може да е била договорена на най-високо ниво между президентите на САЩ и Русия. Официално потвърждение за тези хипотези няма. Но това е мащабна сделка, а петролът винаги е бил геополитика.
Има ли договорка, ще проличи по действията на ΟFAC, която ще трябва да одобри или да отхвърли кандидат-купувача. А макаркомпанията Gunvor Group Ltd. да е един от най-големите търговци на суров петрол в света и да работи в повече от 100 държави, славата ѝ има дълбоки руски корени.
Gunvor e регистрирана в Кипър през 2000 г., а само няколко месеца по-рано международната одиторска компания Arthur Andersen, наета като консултант от Агенцията за приватизация избира „Лукойл“ за купувач на „Нефтохим – Бургас“. Gunvor е създадена от шведа Торбьорн Торнквист и руснака Генадий Тимченко, който е от приближените на президента Путин.
Наскоро той купи дела от 50% на британската Shell в находище за петрол в западната част на Сибир. Forbes го определя като шестия най-богат човек в Русия, с нетно богатство от 23,3 млрд. долара. През 2014 г., буквално часове преди да попадне в списъка на санкционирани руснаци заради руската анексия на Крим, Тимченко продава дела си от 43,5% на своя съдружник Торнквист, който уверява, че компанията не работи с руски петрол, а доставя по-голямата част от нефта си от Северна и Южна Америка.
Според украинското изданиеKyiv Independent „Gunvor e най-големият търговец на руски петрол преди пълномащабната военна инвазия в Украйна“. В свое изявление компанията осъди войната.
За 2024 г. отчетените от Gunvor приходи са за 136 млрд. долара, нетната печалба – 729 млн. долара от търговия с 232 млн. тона петрол.
Тъмните петна на Gunvor
Онова, което липсва в официалния уебсайт на компанията, са разследванията за сделките ѝ в Африка и Латинска Америка. Gunvor e била обект на серия разследвания за подкупи, пране на пари и липса на адекватни мерки за предотвратяване на корупция в няколко държави (Конго, Кот д’Ивоар, Еквадор и др.). През октомври 2019 г. търговецът на петрол е осъден да плати почти 94 млн. швейцарски франка (94,8 млн. долара) заради корупция в Конго и Кот д’Ивоар. Споразумението включва глоба от 4 млн. швейцарски франка (при максимална 5 млн.), както и брутна печалба плюс лихва, реализирана от петролни сделки в двете западноафрикански страни през 2009–2011 г. за стотици милиони долари. През 2023–2024 г. в Швейцария бе повдигнато обвинение срещу бивш финансов мениджър на Gunvor, отговарял за операциите в Конго.
В Еквадор компанията е обвинена в корупционни схеми, при които е плащано, за да бъдат печелени договори и придобивана вътрешна информация от държавната Petroecuador. Част от разследванията са засегнали и други търговци (Vitol, Glencore и др.), твърди Public Eye.
На 1 март Gunvor беше призната за виновна от съдилища в Швейцария и Съединените щати за подкупване на еквадорски длъжностни лица с цел получаване на барели петрол на цени под пазарните между 2013 и 2020 г. Доколкото ни е известно, никой от висшето ръководство на Gunvor досега не е бил разследван. Непубликуван документ, с който разполага Public Eye, показва, че много високопоставен ръководител е осъществявал контакти с Petroecuador, за да улесни сключването на договори за петрол.
На сайта на американското Министерство на правосъдието може да се прочете, че на 1 март 2024 г. (във втория мандат на президента Джо Байдън – б.а.) Gunvor се признава за виновна пред федералния съд в Бруклин и сключва споразумение да заплати над 661 млн. долара (в това число около 375 млн. долара наказателна глоба и над 287 млн. долара конфискация на „недобросъвестни печалби“). Компанията е поела отговорност за действията на някои от бившите си служители.
Подкупването на чуждестранни длъжностни лица окуражава корумпираните служители и подкопава върховенството на закона. Признанието за вина на Gunvor показва, че Наказателният отдел остава решителен в усилията си да изкорени подкупите и корупцията сред длъжностните лица. В координация с нашите международни партньори ще продължим да държим отговорни както корпорациите, така и лицата, които подкупват чуждестранни длъжностни лица.
Брент Уибъл, Министерство на правосъдието на САЩ
Ето тази компания, която анализаторите продължават да смятат за руски аватар, ще придобие активите на „Лукойл“. А те са значими: дял в едни от най-големите петролни находища в света – иракските „Ериду“ и West Qurna-2, от което се добиват над 480 000 барела на ден; дял в находищата „Шах Дениз“ в Азербайджан (19,99%), в „Карачаганак“ и „Тенгиз“ в Казахстан (13,5% и 5%), в „Кандъм-Каузак-Шади“ и „Гисар“ в Узбекистан. „Лукойл“ притежава 10% от нефтения и газов проект „Гаша“ в Абу Даби, а в Мексико съвместно с италианската Eni и мексиканската PetroBal разработва четири блока. В Африка участва в проекти в Гана (Deepwater Tano/Cape Three Points), Египет (West Esh El-Mallaha – WEEM, Meleiha и продължение на WEEM), Камерун (Etinde), Република Конго (Marine XII) и Нигерия (блок OML-140).
Освен рафинериите в България и Румъния руската компания притежава 45% от рафинерията Zeeland в Нидерландия чрез съвместно дружество с френската Total Energies. Компанията управлява мрежа от над 2456 бензиностанции в чужбина.
Заради санкциите на САЩ и Обединеното кралство обаче чуждестранните партньори на „Лукойл“ в тези проекти ще „преоценят“ своето участие. Ако сделката с Gunvor бъде одобрена, Shell, японската Ιnpex и Total Energies може да продължат бизнеса си.
Оттук нататък
Държавите, в които „Лукойл“ и „Роснефт“ имат активи, предприемат различни стъпки. Румъния ще анализира обявената потенциална сделка за активите на „Лукойл“ чрез комисията си, отговорна за чуждестранните инвестиции, стана ясно от изявление на румънското Министерство на енергетиката.
Преди да се вземе каквото и да е решение, е необходимо да се анализира позицията, която ще заеме Европейският съюз, като се има предвид, че Румъния вече прилага режима на санкции на ЕС и ще действа стриктно в тази рамка.
Германия върви към национализация на активите на „Роснефт“. Белград се надява крайният срок да се удължи поне до декември, докато Вашингтон очаква „Газпром“ да продаде дела си в NIS. За дерогация за руския петрол ще моли Тръмп и унгарският президент Виктор Орбан на среща на 7 ноември. Орбан изтъква, че без руски доставки „цените ще скочат“ и икономиката ще се срине, а аргументът му е, че Унгария получава главно руски петрол през тръбопровода „Дружба“. Орбан е под натиск заради предстоящите догодина избори, които предварителните сондажи показват, че ще изгуби.
Какво прави България?
На този фон българските власти не смеят да гъкнат. Упоритите слухове, че „Лукойл“ продава активите си в България, вървят от две години и за кандидати бяха спрягани държавни компании от Азербайджан, Киргизстан и Унгария. Наскоро управляващото мнозинство начело с Борисов/Пеевски прокара скандалната поправка ДАНС да одобрява или отхвърля кандидата за бургаската рафинерия – въпреки че има 17-членен Съвет за скрининг на чуждестранните инвестиции, в който са представени и службите. Тази възможност съществува от 2024 г., когато законът влезе в сила, но прилагането на скрининга се отложи до 22 юли 2025 г., след като бяха приети и публикувани правилниците за прилагане и за дейността на Междуведомствения съвет за скрининг. С ДАНС поправката се прокламира, че ако такива разпоредителни сделки бъдат извършени без подобно одобрение, ще се смятат за нищожни.
Новината за Gunvor свари управляващите неподготвени, а вкарването на особен управител в рафинерията – представител на държавата, който да поеме оперативното ръководство, ги плаши. Тази фигура беше уредена законодателно през 2022 г., когато Русия нападна Украйна. Целта е да действа от името на правителството и да защитава националния интерес.
Засега не е ясно дали българското контраразузнаване може да отхвърли Gunvor като купувач на четирите дружества на „Лукойл“ в България. Ако България може да направи това, значи и останалите европейски държави, където руската компания има активи, трябва да се произнесат. В българския закон за скрининг на чуждестранните инвестиции, който действа и в над 20 държави от ЕС, се изисква съгласуване с Европейската комисия при продажба на стратегически активи. Така че най-напред ще се чака произнасяне на OFAC и ЕК.
Този процес ще отнеме време, а правителството „успокоява“, че горива има до Нова година, тоест за два месеца. Междувременно управляващата коалиция поиска парламентът да забрани износа на дизел и на авиационно гориво.
ГЕРБ предлага да се ограничи износът на дизел и авиационно гориво. Това се прави с цел да се предотврати спекула с цените на горивата и злоупотреба с количествата, които България съхранява.
Делян Добрев
В последната седмица има рязък износ на горива в посока Сърбия, заяви депутатът Ивайло Мирчев (ПП–ДБ), който критикува управляващите, че нямат ясен план и предприемат „пожарни действия“.
Преди близо 10 дни поискахме изслушване в НС на министрите за ситуацията с горивата. Беше ни отказано, а управляващите уверяваха, че всичко е наред и има запаси за 90 дни. Всички знаем, че това са глупости, защото част от търговците на горива не участват в попълването на запаси.
Засега властта е заела любимата поза на българските управници пред (геополитическите) бури – снишаване. Ако обаче не гарантират ритмичния поток на снабдяване с горива, докато чакат решението на Вашингтон, ветровете може и да ги съборят.
Michael Hudson-Doyle, a member of Ubuntu’s Foundations team, has announced
the introduction of an “architecture variant” for Ubuntu 25.10:
By making changes to dpkg, apt and Launchpad, we are able to build
multiple versions of a package, each for a different level of the x86-64 architecture, meaning we can have packages that specifically
target x86-64-v3, for example.
As a result, we’re very excited to share that in Ubuntu 25.10, some
packages are available, on an opt-in basis, in their optimized form
for the more modern x86-64-v3 architecture level.
See the announcement for details on opting in to x86-64-v3
packages.
(аз в момента режа видеата и трябва тия дни да почнем да ги качваме)
По всякакви свидетелски показания, това е най-спокойно протеклия OpenFest до тук, дори от организационна гледна точка 🙂 И въпреки, че организирането никак не беше лесно, определено някакви неща ми бяха липсвали в последните две години.
А не беше лесно. По ред причини трябваше да събирам екип почти наново, да местим инфраструктура, да направим феста две седмици по-рано (не трябваше да се съгласявам, правили сме го и пак беше супер тежко), нова система за подаване на лекции (pretalx), online магазин за запазването на тениски и какво ли не още.
Програмата например се случи много в последния момент – отворихме CFP-то в края на май (от тогава е и първата подадена лекция), но в обявения срок (1 септември) имаше нещо като 34 подадени лекции, workshop-и и щандове, от които повечето в последните три дни. В крайна сметка имахме 74 с две удължавания на срока и ръчкане, но по принцип срок до 1 септември в държава, в която никой не работи през август не беше смислена идея. Та имахме програма по-малко от месец преди събитието, което ми се искаше да не се случва 🙂
(и има още доста неща, от които мога да се оплача, ама те са за postmortem-а)
Но, усещането да идеш в 8 сутринта в събота и да видиш как се върти видеото на телевизорите пред залата, да знаеш, че ей-сега започва и това е резултатът от всичкото това занимаване, или след цялата лудница да влезеш на афтърпартито и да видиш екипът колко се радва на свършената работа (е, и някои от тях да се опитат да те убият с пиене на шотове, вие се знаете кои сте)… Усещах как се ухилвам без да се усетя даже 🙂
(всичко това прави много по-лесно да ходя при доброволците и да питам “Догодина пак?” 🙂 )
От нещата, които много ме зарадваха, че сработиха е новия ни video setup, който ползвахме в голямата зала – изцяло open-source video mixer (има си repo), който успяхме да подкараме в сравнително кратки срокове, с усилията на няколко човека. Имаше малко додебъгване на неща в петък вечер, но двата дни работеше перфектно. Догодина ще гледам всичките ни setup-и да са без proprietary неща.
(бях поканил Марк от FOSDEM да удари едно рамо за видеото, и имаше толкова малко проблеми с цялото нещо, че в крайна сметка той успя да посвири прилично количество време на контрабаса, който бяхме замъкнали в залата)
Организирахме и един music tech jam – Алекс Миланов се сети в последния момент, че можем да направим нещо такова, и събота вечер разни хора се насъбрахме и пробвахме да свирим заедно и да си разменяме инструментите. От там ми е и любимата ми моя снимка от тоя фест.
Също така, имахме нов вариант за запазване/купуване на тениски, през online магазин, който сглобихме заедно с init Lab – избегнахме древните google форми, имахме доста по-добър поглед върху всичко, и успяхме да го навържем с POS терминал и дори да приемаме карти. Имаше някакви количество проблеми, но много по-малко, отколкото очакваме, което се дължи на всички, които участваха в това (и някои даже не спаха една нощ).
(и много много много други неща, дето дори ми е трудно да изброя, все подробности и все важни,
И разбира се, имаше оплаквания, мисля да адресирам няколко от тях:
Едното беше, че сме дали сцена на политическа фигура. Мога много лесно да се оправдая с програмният комитет (в който нямах никакво участие), но това да не се съгласим Божидар Божанов да говори, само заради това е просто тъпо – той е бил лектор по събития и на OpenFest отпреди да я има партията, на която в момента е лидер, свършил е много и полезни неща в и извън политиката, и беше подал лекция, която е важна за OpenFest публиката. Което си личи и от това, че беше много посещавана, мисля и най-гледана на stream-а, и една от най-гласуваните в системата. Та, това е бил съвсем правилен избор.
(по същата тема, хората казват “ама не се политизирайте”. Не съм сигурен как да кажа най-добре “what a load of crap” на български, защото това, че държим на отворени технологии, това, че сме отворени за всякакви хора без значение пол, раса и квото-е-там са си политически позиции, които всъщност защитаваме. Няма да приемем лекция на някой, който иска да забрани open source или да избеси всички бежанци или там каквито е модерно да не се харесват, например.)
Другото беше какви спонсори сме допуснали тази година, т.е. такива, които разработват софтуер за хазарт. Имам съвсем прост отговор на това, който е, че имаше избор между това да се случи и да не се случи OpenFest, мисля, че е очевидно какво избрахме. Ще се радвам много ако не трябва да правя такива избори, но по ред причини се налагаше.
И да приключа с любимата ми снимка от събитието. Двамата Ивановци и някакви хора липсват, че имаше малко объркване с програмата, та чакаме някой да ги photoshop-не в снимката…
In September 2025, a thread popped up in our internal engineering chat room asking, “Which part of our stack would be responsible for sending ErrCode=ENHANCE_YOUR_CALM to an HTTP/2 client?” Two internal microservices were experiencing a critical error preventing their communication and the team needed a timely answer.
In this blog post, we describe the background to well-known HTTP/2 attacks that trigger Cloudflare defences, which close connections. We then document an easy-to-make mistake using Go’s standard library that can cause clients to send PING flood attacks and how you can avoid it.
HTTP/2 is powerful – but it can be easy to misuse
HTTP/2 defines a binary wire format for encoding HTTP semantics. Request and response messages are encoded as a series of HEADERS and DATA frames, each associated with a logical stream, sent over a TCP connection using TLS. There are also control frames that relate to the management of streams or the connection as a whole. For example, SETTINGS frames advertise properties of an endpoint, WINDOW_UPDATE frames provide flow control credit to a peer so that it can send data, RST_STREAM can be used to cancel or reject a request or response, while GOAWAY can be used to signal graceful or immediate connection closure.
HTTP/2 provides many powerful features that have legitimate uses. However, with great power comes responsibility and opportunity for accidental or intentional misuse. The specification details a number of denial-of-service considerations. Implementations are advised to harden themselves: “An endpoint that doesn’t monitor use of these features exposes itself to a risk of denial of service. Implementations SHOULD track the use of these features and set limits on their use.”
Cloudflare implements many different HTTP/2 defenses, developed over years in order to protect our systems and our customers. Some notable examples include mitigations added in 2019 to address “Netflix vulnerabilities” and in 2023 to mitigate Rapid Reset and similar style attacks.
When Cloudflare detects that HTTP/2 client behaviour is likely malicious, we close the connection using the GOAWAY frame and include the error code ENHANCE_YOUR_CALM.
One of the well-known and common attacks is CVE-2019-9512, aka PING flood: “The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.” Sending a PING frame causes the peer to respond with a PING acknowledgement (indicated by an ACK flag). This allows for checking the liveness of the HTTP connection, along with measuring the layer 7 round-trip time – both useful things. The requirement to acknowledge a PING, however, provides the potential attack vector since it generates work for the peer.
A client that PINGs the Cloudflare edge too frequently will trigger our CVE-2019-9512 mitigations, causing us to close the connection. Shortly after we launched support for gRPC in 2020, we encountered interoperability issues with some gRPC clients that sent many PINGs as part of a performance optimization for window tuning. We also discovered that the Rust Hyper crate had a feature called Adaptive Window that emulated the design and triggered a similar problem until Hyper made a fix.
Solving a microservice miscommunication mystery
When that thread popped up asking which part of our stack was responsible for sending the ENHANCE_YOUR_CALM error code, it was regarding a client communicating over HTTP/2 between two internal microservices.
We suspected that this was an HTTP/2 mitigation issue and confirmed it was a PING flood mitigation in our logs. But taking a step back, you may wonder why two internal microservices are communicating over the Cloudflare edge at all, and therefore hitting our mitigations. In this case, communicating over the edge provides us with several advantages:
We get to dogfood our edge infrastructure and discover issues like this!
We can use Cloudflare Access for authentication. This allows our microservices to be accessed securely by both other services (using service tokens) and engineers (which is invaluable for debugging).
Internal services that are written with Cloudflare Workers can easily communicate with services that are accessible at the edge.
The question remained: Why was this client behaving this way? We traded some ideas as we attempted to get to the bottom of the issue.
The client had a configuration that would indicate that it didn’t need to PING very frequently:
However, in situations like this it is generally a good idea to establish ground truth about what is really happening “on the wire.” For instance, grabbing a packet capture that can be dissected and explored in Wireshark can provide unequivocal evidence of precisely what was sent over the network. The next best option is detailed/trace logging at the sender or receiver, although sometimes logging can be misleading, so caveat emptor.
In our particular case, it was simpler to use logging with GODEBUG=http2debug=2. We built a simplified minimal reproduction of the client that triggered the error, helping to eliminate other potential variables. We did some group log analysis, combined with diving into some of the Go standard library code to understand what it was really doing. Issac Asimov is commonly credited with the quote “The most exciting phrase to hear in science, the one that heralds new discoveries, is not ‘Eureka!’ but ‘That’s funny…'” and sure enough, within the hour someone declared–
the funny part I see is this:
2025/09/02 17:33:18 http2: Framer 0x14000624540: wrote RST_STREAM stream=9 len=4 ErrCode=CANCEL
2025/09/02 17:33:18 http2: Framer 0x14000624540: wrote PING len=8 ping="j\xe7\xd6R\xdaw\xf8+"
every ping seems to be preceded by a RST_STREAM
Observant readers will recall the earlier mention of Rapid Reset. However, our logs clearly indicated ENHANCE_YOUR_CALM being triggered due to the PING flood. A bit of searching landed us on this mailing list thread and the comment “Sending a PING frame along with an RST_STREAM allows a client to distinguish between an unresponsive server and a slow response.” That seemed quite relevant. We also found a change that was committed related to this topic. This partly answered why there were so many PINGs, but it also raised a new question: Why so many stream resets?
So we went back to the logs and built up a little more context about the interaction:
2025/09/02 17:33:18 http2: Transport received DATA flags=END_STREAM stream=47 len=0 data=""
2025/09/02 17:33:18 http2: Framer 0x14000624540: wrote RST_STREAM stream=47 len=4 ErrCode=CANCEL
2025/09/02 17:33:18 http2: Framer 0x14000624540: wrote PING len=8 ping="\x97W\x02\xfa>\xa8\xabi"
The interesting thing here is that the server had sent a DATA frame with the END_STREAM flag set. Per the HTTP/2 stream state machine, the stream should have transitioned to closed when a frame with END_STREAM was processed. The client doesn’t need to do anything in this state – sending a RST_STREAM is entirely unnecessary.
A little more digging and noodling and an engineer proclaimed:
I noticed that the reset+ping only happens when you call resp.Body.Close()
I believe Go’s HTTP library doesn’t actually read the response body automatically, but keeps the stream open for you to use until you call resp.Body.Close(), which you can do at any point you like.
The hilarious thing in our example was that there wasn’t actually any HTTP body to read. From the earlier example: received DATA flags=END_STREAM stream=47 len=0 data="".
Science and engineering are at times weird and counterintuitive. We decided to tweak our client to read the (absent) body via io.Copy(io.Discard, resp.Body) before closing it.
Sure enough, this immediately stopped the client sending both a useless RST_STREAM and, by association, a PING frame.
Mystery solved?
To prove we had fixed the root cause, the production client was updated with a similar fix. A few hours later, all the ENHANCE_YOUR_CALM closures were eliminated.
Reading bodies in Go can be unintuitive
It’s worth noting that in some situations, ensuring the response body is always read can sometimes be unintuitive in Go. For example, at first glance it appears that the response body will always be read in the following example:
However, json.Decoder stops reading as soon as it finds a complete JSON document or errors. If the response body contains multiple JSON documents or invalid JSON, then the entire response body may still not be read.
Therefore, in our clients, we’ve started replacing defer response.Body.Close() with the following pattern to ensure that response bodies are always fully read:
Actions to take if you encounter ENHANCE_YOUR_CALM
HTTP/2 is a protocol with several features. Many implementations have implemented hardening to protect themselves from misuse of features, which can trigger a connection to be closed. The recommended error code for closing connections in such conditions is ENHANCE_YOUR_CALM. There are numerous HTTP/2 implementations and APIs, which may drive the use of HTTP/2 features in unexpected ways that could appear like attacks.
If you have an HTTP/2 client that encounters closures with ENHANCE_YOUR_CALM, we recommend that you try to establish ground truth with packet captures (including TLS decryption keys via mechanisms like SSLKEYLOGFILE) and/or detailed trace logging. Look for patterns of frequent or repeated frames that might be similar to malicious traffic. Adjusting your client may help avoid it getting misclassified as an attacker.
If you use Go, we recommend always reading HTTP/2 response bodies (even if empty) in order to avoid sending unnecessary RST_STREAM and PING frames. This is especially important if you use a single connection for multiple requests, which can cause a high frequency of these frames.
This was also a great reminder of the advantages of dogfooding our own products within our internal services. When we run into issues like this one, our learnings can benefit our customers with similar setups.
Below, co-authors Bruce Schneier and Nathan E. Sanders share five key insights from their new book, Rewiring Democracy: How AI Will Transform Our Politics, Government, and Citizenship.
What’s the big idea?
AI can be used both for and against the public interest within democracies. It is already being used in the governing of nations around the world, and there is no escaping its continued use in the future by leaders, policy makers, and legal enforcers. How we wire AI into democracy today will determine if it becomes a tool of oppression or empowerment.
1. AI’s global democratic impact is already profound.
It’s been just a few years since ChatGPT stormed into view and AI’s influence has already permeated every democratic process in governments around the world:
In 2022, an artist collective in Denmark founded the world’s first political party committed to an AI-generated policy platform.
Also in 2022, South Korean politicians running for the presidency were the first to use AI avatars to communicate with voters en masse.
In 2023, a Brazilian municipal legislator passed the first enacted law written by AI.
In 2024, a U.S. federal court judge started using AI to interpret the plain meaning of words in U.S. law.
Also in 2024, the Biden administration disclosed more than two thousand discrete use cases for AI across the agencies of the U.S. federal government.
The examples illustrate the diverse uses of AI across citizenship, politics, legislation, the judiciary, and executive administration.
Not all of these uses will create lasting change. Some of these will be one-offs. Some are inherently small in scale. Some were publicity stunts. But each use case speaks to a shifting balance of supply and demand that AI will increasingly mediate.
Legislators need assistance drafting bills and have limited staff resources, especially at the local and state level. Historically, they have looked to lobbyists and interest groups for help. Increasingly, it’s just as easy for them to use an AI tool.
2. The first places AI will be used are where there is the least public oversight.
Many of the use cases for AI in governance and politics have vocal objectors. Some make us uncomfortable, especially in the hands of authoritarians or ideological extremists.
In some cases, politics will be a regulating force to prevent dangerous uses of AI. Massachusetts has banned the use of AI face recognition in law enforcement because of real concerns voiced by the public about their tendency to encode systems of racial bias.
Some of the uses we think might be most impactful are unlikely to be adopted fast because of legitimate concern about their potential to make mistakes, introduce bias, or subvert human agency. AIs could be assistive tools for citizens, acting as their voting proxies to help us weigh in on larger numbers of more complex ballot initiatives, but we know that many will object to anything that verges on AIs being given a vote.
But AI will continue to be rapidly adopted in some aspects of democracy, regardless of how the public feels. People within democracies, even those in government jobs, often have great independence. They don’t have to ask anyone if it’s ok to use AI, and they will use it if they see that it benefits them. The Brazilian city councilor who used AI to draft a bill did not ask for anyone’s permission. The U.S. federal judge who used AI to help him interpret law did not have to check with anyone first. And the Trump administration seems to be using AI for everything from drafting tariff policies to writing public health reports—with some obvious drawbacks.
It’s likely that even the thousands of disclosed AI uses in government are only the tip of the iceberg. These are just the applications that governments have seen fit to share; the ones they think are the best vetted, most likely to persist, or maybe the least controversial to disclose.
3. Elites and authoritarians will use AI to concentrate power.
Many Westerners point to China as a cautionary tale of how AI could empower autocracy, but the reality is that AI provides structural advantages to entrenched power in democratic governments, too. The nature of automation is that it gives those at the top of a power structure more control over the actions taken at its lower levels.
It’s famously hard for newly elected leaders to exert their will over the many layers of human bureaucracies. The civil service is large, unwieldy, and messy. But it’s trivial for an executive to change the parameters and instructions of an AI model being used to automate the systems of government.
The dynamic of AI effectuating concentration of power extends beyond government agencies. Over the past five years, Ohio has undertaken a project to do a wholesale revision of its administrative code using AI. The leaders of that project framed it in terms of efficiency and good governance: deleting millions of words of outdated, unnecessary, or redundant language. The same technology could be applied to advance more ideological ends, like purging all statutory language that places burdens on business, neglects to hold businesses accountable, protects some class of people, or fails to protect others.
Whether you like or despise automating the enactment of those policies will depend on whether you stand with or are opposed to those in power, and that’s the point. AI gives any faction with power the potential to exert more control over the levers of government.
4. Organizers will find ways to use AI to distribute power instead.
We don’t have to resign ourselves to a world where AI makes the rich richer and the elite more powerful. This is a technology that can also be wielded by outsiders to help level the playing field.
In politics, AI gives upstart and local candidates access to skills and the ability to do work on a scale that used to only be available to well-funded campaigns. In the 2024 cycle, Congressional candidates running against incumbents like Glenn Cook in Georgia and Shamaine Daniels in Pennsylvania used AI to help themselves be everywhere all at once. They used AI to make personalized robocalls to voters, write frequent blog posts, and even generate podcasts in the candidate’s voice. In Japan, a candidate for Governor of Tokyo used an AI avatar to respond to more than eight thousand online questions from voters.
Outside of public politics, labor organizers are also leveraging AI to build power. The Worker’s Lab is a U.S. nonprofit developing assistive technologies for labor unions, like AI-enabled apps that help service workers report workplace safety violations. The 2023 Writers’ Guild of America strike serves as a blueprint for organizers. They won concessions from Hollywood studios that protect their members against being displaced by AI while also winning them guarantees for being able to use AI as assistive tools to their own benefit.
5. The ultimate democratic impact of AI depends on us.
If you are excited about AI and see the potential for it to make life, and maybe even democracy, better around the world, recognize that there are a lot of people who don’t feel the same way.
If you are disturbed about the ways you see AI being used and worried about the future that leads to, recognize that the trajectory we’re on now is not the only one available.
The technology of AI itself does not pose an inherent threat to citizens, workers, and the public interest. Like other democratic technologies—voting processes, legislative districts, judicial review—its impacts will depend on how it’s developed, who controls it, and how it’s used.
Constituents of democracies should do four things:
Reform the technology ecosystem to be more trustworthy, so that AI is developed with more transparency, more guardrails around exploitative use of data, and public oversight.
Resist inappropriate uses of AI in government and politics, like facial recognition technologies that automate surveillance and encode inequity.
Responsibly use AI in government where it can help improve outcomes, like making government more accessible to people through translation and speeding up administrative decision processes.
Renovate the systems of government vulnerable to the disruptive potential of AI’s superhuman capabilities, like political advertising rules that never anticipated deepfakes.
These four Rs are how we can rewire our democracy in a way that applies AI to truly benefit the public interest.
This essay was written with Nathan E. Sanders, and originally appeared in The Next Big Idea Club.
EDITED TO ADD (11/6): This essay was republished by Fast Company.
Всички трябва да участваме в скандали и да спрем да твърдим. Ако ви звучим като Делян Пеевски с принтирани снимки в ръка, много добре – така ще е отсега нататък. Подробности от Е.Т.
Какво е човекът – маймуна, която говори и може да ходи предимно на двата си крака в изправена поза и с поглед, от който се вижда, че може да мисли и чувства свободно, но нерядко е роб, глух и ням, най-добрият свидетел? Какво е човекът – многоклетъчно тяло от сбор елементи, уникална подвижна централа за биохимични процеси; малък свят, като капка, който целия свят отразява, както него светът, докато неусетно се смесят? Какво е човекът – евреин, индус, бежанец, европеец или циганин, който прескача от Макондо до Охрид да разкаже набързо история или някоя песен да запее протяжно на българска привечер в Струга? Какво е човекът все по-малко разбирам и зная, но така ми прилича на ангел, когато си мисли за рая.
Людмила Миндова
Людмила Миндова (р. 1974) е поетеса, писателка, преводачка на художествена литература и литературоведка. Публикувала е книги с поезия, белетристика и изследвания в областта на славянските и балканските литератури. В неин превод са издадени произведения на автори от бившето югославско пространство, сред които Данило Киш, Дубравка Угрешич, Йосип Ости, Алеш Дебеляк, Томаж Шаламун и др. Доцент е в Института за балканистика с Център по тракология „Проф. Александър Фол“.
Според Екатерина Йосифова „четящият стихотворение сутрин… добре понася другите часове“ от деня. Убедени, че поезията държи умовете ни будни, а сърцата – отворени, в края на всеки месец ви предлагаме по едно стихотворение. Защото и в най-смутни времена доброто стихотворение е добра новина.
My first introduction to the Prometheus project was through the Linux Foundation mentorship program,
where I conducted UX research. I remember the anxiety I felt when I was selected as a mentee. I was new not just to Prometheus,
but to observability entirely. I worried I was in over my head, working in a heavily developer-focused domain with no development background.
That anxiety turned out to be unfounded. I went on to make meaningful contributions to the project, and I’ve learned that what I
experienced is nearly universal among non-technical contributors to open source.
If you’re feeling that same uncertainty, this post is for you. I’ll share the challenges you’re likely to face (or already face),
why your contributions matter, and how to find your place in the Prometheus community.
The Challenges Non-Technical Contributors Face
As a non-technical contributor, I’ve had my share of obstacles in open source. And from conversations with others navigating these spaces,
I’ve found the struggles are remarkably consistent. Here are the most common barriers:
1. The Technical Intimidation Factor
I’ve felt out of place in open source spaces, mostly because technical contributors vastly outnumber non-technical ones. Even the non-technical
people often have technical backgrounds or have been around long enough to understand what’s happening.
When every conversation references concepts you don’t know, it’s easy to feel intimidated. You join meetings and stay silent throughout.
You respond in the chat instead of unmuting because you don’t trust yourself to speak up in a recorded meeting where everyone else seems
fluent in a technical language you’re still learning.
2. Unclear Value Proposition
Open source projects rarely spell out their non-technical needs the way a job posting would. You would hardly find an issue titled
“Need: someone to interview users and write case studies” or “Wanted: community manager to organize monthly meetups.” Instead, you’re
more likely to see a backlog of GitHub issues about bugs, feature requests, and code refactoring.
Even if you have valuable skills, you don’t know where they’re needed, how to articulate your value, or whether your contributions will
be seen as mission-critical or just nice-to-have. Without a clear sense of how you fit in, it’s difficult to reach out confidently.
You end up sending vague messages like “I’d love to help! Let me know if there’s anything I can do”, which rarely leads anywhere because
maintainers are busy and don’t have time to figure out how to match your skills to their needs.
3. Lack of Visible Non-Technical Contributors
One of the things that draws me to an open source community or project is finding other people like me. I think it’s the same way for most people.
Representation matters. It’s hard to be what you can’t see.
It’s even more difficult to find non-technical contributors because their contributions are often invisible in the ways projects typically showcase work.
GitHub contribution graphs count commits. Changelogs list code changes and bug fixes. You only get the “contributor” label when you’ve created a
pull request that got merged. So, even when people are organizing events, supporting users, or conducting research, their work doesn’t show up in
the same prominent ways code does.
4. The Onboarding Gap
A typical “Contributing Guide” will walk you through setting up a development environment, creating a branch, running tests, and submitting a pull request.
But it rarely explains how to contribute documentation improvements, where design feedback should go, or how community support is organized.
You see “Join our community” with a link to a Slack workspace. But between joining and making your first contribution, there’s a significant gap.
There are hundreds of people in dozens of channels. Who’s a maintainer and who’s just another community member? Which channel is appropriate for
your questions? Who should you tag when you need guidance?
Why These Gaps Exist
It’s worth acknowledging that most of the time, these gaps aren’t intentional. Projects don’t set out to exclude non-technical contributors or
make it harder for them to participate.
In most cases, a small group of developers build something useful and decide to open-source it. They invite people they know who might need it
(often other developers) to contribute. The project grows organically within those networks. It becomes a community of developers building
tools for developers, and certain functions simply don’t feel necessary yet. Marketing? The word spreads naturally through tech circles.
Community management? The community is small and self-organizing. UX design? They’re developers comfortable with command-line interfaces,
so they may not fully consider the experience of using a graphical interface.
None of this is malicious. It’s just that the project evolved in a context where those skills weren’t obviously needed.
The shift happens when someone, often a non-technical contributor who sees the potential, steps in and says:
“You’ve built something valuable and grown an impressive community. But here’s what you might be missing.
Here’s how documentation could lower the barrier to entry. Here’s how community management could retain contributors.
Here’s how user research could guide your roadmap.”
Why Non-Technical Contributions Matter
Prometheus is a powerful monitoring system backed by a large community of developers. But like any open source project, it needs more than code to thrive.
It needs accessible documentation. From my experience working with engineers, most would rather focus on building than writing docs,
and understandably so. Engineers who know the system inside out often write documentation that assumes knowledge newcomers don’t have.
What makes perfect sense to someone who built the feature can feel impenetrable to someone encountering it for the first time.
A technical writer testing the product from an end user’s perspective, not a builder’s, can bridge that gap and lower the barrier to entry.
It needs organization. The GitHub issues backlog has hundreds of open items that haven’t been triaged. Maintainers spend valuable
time parsing what users actually need instead of building solutions. A project manager or someone with triage experience could turn
that chaos into a clear roadmap, allowing maintainers to spend their time building solutions.
It needs community support. Imagine a user who joins the Slack workspace, excited to contribute. They don’t know where to start.
They ask a question that gets buried in the stream of messages. They quietly leave. The project just lost a potential contributor because
no one was there to welcome them and point them in the right direction.
These are the situations non-technical contributions can help prevent. Good documentation lowers the barrier to entry, which means more adoption,
more feedback, and better features. Active community management retains contributors who would otherwise drift away, which means distributed
knowledge and less maintainer burnout. Organization and triage turn scattered input into actionable priorities.
The Prometheus maintainers are doing exceptional work building a robust, scalable monitoring system. But they can’t do everything,
and they shouldn’t have to. The question now isn’t whether non-technical contributions matter. It’s whether we create the space for them to happen.
Practical Ways You Can Contribute to Prometheus
If you’re ready to contribute to Prometheus but aren’t sure where to start, here are some areas where non-technical skills are actively needed.
1. Join the UX Efforts
Prometheus is actively working to improve its user experience, and the community now has a UX Working Group dedicated to this effort.
If you’re a UX researcher, designer, or someone with an eye for usability, this is an excellent time to get involved.
The working group is still taking shape, with ongoing discussions about priorities and processes.
Join the Slack channel to participate in these conversations and watch for upcoming announcements about specific ways to contribute.
I can tell you from experience that the community is receptive to UX contributions, and your work will have a real impact.
2. Write for the Prometheus Blog
If you’re a technical writer or content creator, the Prometheus blog is a natural entry point. The blog publishes tutorials,
case studies, best practices, community updates, and generally, content that helps users get more value from Prometheus.
Check out the blog content guide to understand what makes a strong blog proposal and how to publish a post on the blog.
There’s an audience eager to learn from your experience.
3. Improve and Maintain Documentation
Documentation is one of those perpetual needs in open source. There’s always something that could be clearer, more complete, or better organized.
The Prometheus docs repo is no exception.
You can contribute by fixing typos and broken links, expanding getting-started guides,
creating tutorials for common monitoring scenarios, or triaging issues to help
prioritize what needs attention. Even if you don’t consider yourself a technical writer, if you’ve ever been confused by the docs and
figured something out, you can help make it clearer for the next person.
4. Help Organize PromCon
PromCon is Prometheus’s annual conference, and it takes significant coordination to pull off.
The organizing team handles everything from speaker selection and scheduling to venue logistics and sponsor relationships.
If you have experience in event planning, sponsor outreach, marketing, or communications, the PromCon organizers would welcome your help.
Reach out to the organizing team or watch for announcements in the Prometheus community channels.
5. Advocate and Amplify
Finally, one of the simplest but most impactful things you can do is talk about Prometheus. Write blog posts about how you’re using Prometheus.
Give talks at local meetups or conferences. Share tips and learnings on social media. Create video tutorials or live streams.
Recommend Prometheus to teams evaluating monitoring solutions.
Every piece of content, every conference talk, every social media post expands Prometheus’s reach and helps new users discover it.
How to Get Started
If you’re ready to contribute to Prometheus, here’s what I’ve learned from my own experience navigating the community as a non-technical contributor:
Start by introducing yourself. When you join the #prometheus-dev Slack channel, say hello. Slack doesn’t always make it obvious
when someone new joins, so if you stay silent, people simply won’t know you’re there. A simple introduction—your name, what you do, what brought you to Prometheus—is enough to make your presence known.
Attend community meetings. Check out the community calendar and
sync the meetings that interest you. Even if you don’t understand everything being discussed at first (and that’s completely normal), stay.
The more you sit in, the more you’ll learn about the community’s needs and find more opportunities to contribute.
Observe before you act. It’s tempting to jump in with ideas immediately, but spending time as an observer first pays off.
Read through Slack discussions and conversations in GitHub issues. Browse the documentation. Notice what kinds of contributions are being made.
You’ll start to see patterns: recurring questions, documentation gaps, areas where help is needed. That’s where your opportunity lies.
Ask questions. Everyone was new once. If something isn’t clear, ask. If you don’t get a response right away,
give it some time—people are busy—then follow up. The community is welcoming, but you have to make yourself visible.
The Prometheus community has room for you. Now you know exactly where to begin.
As bots and agents start cryptographically signing their requests, there is a growing need for website operators to learn public keys as they are setting up their service. I might be able to find the public key material for well-known fetchers and crawlers, but what about the next 1,000 or next 1,000,000? And how do I find their public key material in order to verify that they are who they say they are? This problem is called discovery.
We share this problem with Amazon Bedrock AgentCore, a comprehensive agentic platform to build, deploy and operate highly capable agents at scale, and their AgentCore Browser, a fast, secure, cloud-based browser runtime to enable AI agents to interact with websites at scale. The AgentCore team wants to make it easy for each of their customers to sign their own requests, so that Cloudflare and other operators of CDN infrastructure see agent signatures from individual agents rather than AgentCore as a monolith. (Note: this method does not identify individual users.) In order to do this, Cloudflare needed a way to ingest and register the public keys of AgentCore’s customers at scale.
In this blog post, we propose a registry of bots and agents as a way to easily discover them on the Internet. We also outline how Web Bot Auth can be expanded with a registry format. Similar to IP lists that can be authored by anyone and easily imported, the registry format is a list of URLs at which to retrieve agent keys and can be authored and imported easily.
We believe such registries should foster and strengthen an open ecosystem of curators that website operators can trust.
A need for more trustworthy authentication
In May, we introduced a protocol proposal called Web Bot Auth, which describes how bot and agent developers can cryptographically sign requests coming from their infrastructure.
There have now been multiple implementations of the proposed protocol, from Vercel to Shopify to Visa. It has been actively discussed and contributions have been made. Web Bot Auth marks a first step towards moving from brittle identification, like IPs and user agents, to more trustworthy cryptographic authentication. However, like IP addresses, cryptographic keys are a pseudonymous form of identity. If you operate a website without the scale and reach of large CDNs, how do you discover the public key of known crawlers?
The first protocol proposal suggested one approach: bot operators would provide a newly-defined HTTP header Signature-Agent that refers to an HTTP endpoint hosting their keys. Similar to IP addresses, the default is to allow all, but if a particular operator is making too many requests, you can start taking actions: increase their rate limit, contact the operator, etc.
With all that in mind, we come to the following problem. How can Cloudflare ensure customers have control over the traffic they want to allow, with sensible defaults, while fostering an open curation ecosystem that doesn’t lock in customers or small origins?
Such an ecosystem exists for lists of IP addresses (e.g. avestel-bots-ip-lists) and robots.txt (e.g. ai-robots-txt). For both, you can find canonical lists on the Internet to easily configure your website to allow or disallow traffic from those IPs. They provide direct configuration for your nginx or haproxy, and you can use it to configure your Cloudflare account. For instance, I could import the robots.txt below:
User-agent: MyBadBot
Disallow: /
This is where the registry format comes in, providing a list of URLs pointing to Signature Agent keys:
# AI Crawler
https://chatgpt.com/.well-known/http-message-signatures-directory
https://autorag.ai.cloudflare.com/.well-known/http-message-signatures-directory
# Test signature agent card
https://http-message-signatures-example.research.cloudflare.com/.well-known/http-message-signatures-directory
And that’s it. A registry could contain a list of all known signature agents, a curated list for academic research agents, for search agents, etc.
Anyone can maintain and host these lists. Similar to IP or robots.txt list, you can host such a registry on any public file system. This means you can have a repository on GitHub, put the file on Cloudflare R2, or send it as an email attachment. Cloudflare intends to provide one of the first instances of this registry, so that others can contribute to it or reference it when building their own.
Learn more about an incoming request
Knowing the Signature-Agent is great, but not sufficient. For instance, to be a verified bot, Cloudflare requires a contact method, in case requests from that infrastructure suddenly fail or change format in a way that causes unexpected errors upstream. In fact, there is a lot of information an origin might want to know: a name for the operator, a contact method, a logo, the expected crawl rate, etc.
Therefore, to complement the registry format, we have proposed a signature-agent card format that extends the JWKS directory (RFC 7517) with additional metadata. Similar to an old-fashioned contact card, it includes all the important information someone might want to know about your agent or crawler.
We provide an example below for illustration. Note that the fields may change: introducing jwks-uri, logo being more descriptive, etc.
Amazon Bedrock AgentCore, an agentic platform for building and deploying AI agents at scale, adopted Web Bot Auth for its AgentCore Browser service (learn more in their post). AgentCore Browser intends to transition from a service signing key that is currently available in their public preview, to customer-specific keys, once the protocol matures. Cloudflare and other operators of origin protection service will be able to see and validate signatures from individual AgentCore customers rather than AgentCore as a whole.
Cloudflare also offers a registry for bots and agents it trusts, provided through Radar. It uses the registry format to allow for the consumption of bots trusted by Cloudflare on your server.
You can use these registries today – we’ve provided a demo in Go for Caddy server that would allow us to import keys from multiple registries. It’s on cloudflare/web-bot-auth. The configuration looks like this:
:8080 {
route {
# httpsig middleware is used here
httpsig {
registry "http://localhost:8787/test-registry.txt"
# You can specify multiple registries. All tags will be checked independantly
registry "http://example.test/another-registry.txt"
}
# Responds if signature is valid
handle {
respond "Signature verification succeeded!" 200
}
}
}
There are several reasons why you might want to operate and curate a registry leveraging the Signature Agent Card format:
Monitor incoming Signature-Agents. This should allow you to collect signature-agent cards of agents reaching out to your domain.
Import them from existing registries, and categorize them yourself. There could be a general registry constructed from the monitoring step above, but registries might be more useful with more categories.
Establish direct relationships with agents. Cloudflare does this for itsbot registry for instance, or you might use a public GitHub repository where people can open issues.
Learn from your users. If you offer a security service, allowing your customers to specify the registries/signature-agents they want to let through allows you to gain valuable insight.
Moving forward
As cryptographic authentication for bots and agents grows, the need for discovery increases.
With the introduction of a lightweight format and specification to attach metadata to Signature-Agent, and curate them in the form of registries, we begin to address this need. The HTTP Message Signature directory format is being expanded to include some self-certified metadata, and the registry maintains a curation ecosystem.
Down the line, we predict that clients and origins will choose the signature-agent they trust, use a common format to migrate their configuration between CDN providers, and rely on a third-party registry for curation. We are working towards integrating these capabilities into our bot management and rule engines.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
