What’s changed?

• Fixed an edge-case bug in SyncJS’ RunAsync() function, which on POSIX systems could leave behind a zombie process if used to invoke a shell with a command line to execute a shell-script (very uncommon, but possible nonetheless)

• Added CtxVirtualSite() to the SyncJS scripting engine

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

SFTP-as-a-service asks for something different. It asks for your files, or the keys to get to them itself.

The trade nobody names out loud

Sign up for almost any managed SFTP or SFTP-as-a-service product and the pitch sounds the same: stop running your own server, stop patching, stop worrying about uptime. Let us handle it. Fair enough. Running SFTP infrastructure yourself is genuinely tedious (and often complicated) work, and offloading it is a real win.

But “let us handle it” almost always expands into “let us handle your files too.” Somewhere between signing up and your first transfer, one of two things happens:

• Your files land on the vendor’s cloud, sometimes briefly, sometimes permanently.

• Or, increasingly common, the vendor connects directly to your own S3, GCS, or Azure Blob storage, which means you hand over the credentials to do it: access keys, IAM roles, service accounts. The files never move, but the vendor now holds a set of keys that can reach in and take them whenever it wants.

Neither of those is optional in most SaaS SFTP products today. It’s their architecture, full stop. And the second pattern is easy to overlook, because nothing about it feels like “giving up your files.” It just feels like configuring a connection. The access is the same either way.

Why this became “normal”

It became normal for a boring, understandable reason: it’s the easiest way to build the product. If the vendor’s cloud is a waypoint your files pass through, or if the vendor has standing access to your bucket, the engineering is straightforward. Most of the category was built this way because most of the category needed to ship fast.

That doesn’t make it a requirement. It makes it a default that stuck around long enough to look like one.

The question worth asking

If the entire value of “as-a-service” is convenience, and the entire cost is access to your data, the real question isn’t “is this convenient.” Of course it is. The question is: does the convenience actually require the access?

Put another way: could a service manage the server, handle the protocol, take care of authentication and monitoring and all the operational weight, without ever needing to see, hold, or reach directly into your files?

We think the answer is yes. That’s the premise we’ve been building SFTP.cloud around: all of the “as-a-service” convenience, none of the “give us access to your data” part of the deal. And this diagram shows you how we did it.

Surprise! The compromise most of this category treats as inevitable turns out to be a choice, not a constraint.

What to watch for

If you’re currently comparing SFTP-as-a-service options, a compromise-free product should be identifiable by what it doesn’t ask you for:

• It shouldn’t need standing access into your storage, and it shouldn’t need your credentials to get it.

• It shouldn’t need your files to be cached or sit on its infrastructure at any point, ever.

• It shouldn’t care whether your storage is in the cloud or sitting in your own data center.

If a vendor can’t say yes to all three, you haven’t found the compromise-free version. You’ve found the default one.

We’re building SFTP.cloud to be the SFTP-SaaS that doesn’t ask for the trade. Early access is open to the first 100 people who want in: reserve your spot at SFTP.cloud. Not ready to commit yet? Subscribe to this blog and we’ll keep you posted.

What’s changed?

• Added a two-fold protection shield against Windows’ IRP leakage bug when remote storage accessed via SMB/CIFS becomes unavailable mid-session (this is a Windows bug, not ours, but we can now work around it)

• Added CtxUsername() to the SyncJS scripting engine

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

That’s not an accident. “Cloud SFTP” isn’t one thing. It’s three very different architectures wearing the same marketing label, and the differences between them matter a lot more than most vendors want you to notice.

If you’re evaluating a cloud SFTP solution, you need to know which one you’re actually looking at.

Flavor 1: “Cloud” just means “on a VM”

The oldest trick in the book. Take a normal SFTP server, install it on an EC2 instance or an Azure VM, call it “cloud SFTP.”

Nothing about the security model changes. You still patch it. You still manage the firewall. You still own every CVE that lands on it. The only thing that moved to the cloud is the hardware. This isn’t wrong, exactly, but it’s just not what most people mean when they ask for a managed cloud SFTP service.

Flavor 2: The vendor hosts it, and your files

This is what most people actually get when they sign up for a “cloud SFTP” or “SFTP-as-a-service” product today. The vendor runs the server. Convenient. But look closer at where your files actually live during and after a transfer, and the picture gets less comfortable:

• Your files are stored on the vendor’s infrastructure, at least transiently, often persistently.

• To connect your own storage, you typically have to grant the vendor access into it: an S3 bucket policy, a service account, an API key with read/write scope.

• If your storage isn’t cloud-native (an on-prem NAS, a SAN, a file server sitting in your own data center) you’re usually out of luck. Cloud-only storage backends are the norm, not on-prem.

• And on the storage side, inbound firewall rules are still the default, because something still needs to reach in and grab the files.

None of this makes a vendor incompetent. It’s just the architecture almost everyone builds, because it’s the easiest one to build. But “managed” quietly became a synonym for “someone else has access to your data,” and that trade got baked-in so early that nobody even questions it anymore.

Flavor 3: The one nobody’s really built yet (except…)

Here’s the question worth sitting with: why does a managed file transfer service need access to your files at all?

Not “why does it need to move them,” obviously it does, that’s the job. The question is why the vendor’s cloud needs to be a place your files sit in, or are even briefly accessible from. What if the cloud component only ever relayed a protocol, never held a byte of your data, and the connection into your storage only ever went outward, meaning nothing on the internet ever needs an open inbound port to reach it?

That’s not a rhetorical question. It’s the design question we’ve been working through at Syncplify for our upcoming sftp.cloud service, and we’ve already shared a piece of it: files that are never stored in our cloud, not during transfer, not at rest, not ever, paired with a lightweight connector that opens an outbound-only connection from wherever your storage actually lives.

We’re not ready to walk you through the full architecture yet. But we’ll say this much: if your current “cloud SFTP” vendor needs an inbound rule on your firewall, or needs permission to reach into your storage, that’s not an inherent requirement of the category. It’s just the version that got built first. And SFTP.cloud is designed to subvert that requirement.

What to actually ask

Next time someone pitches you a cloud SFTP or managed SFTP product, three questions cut through the marketing fast:

1. Does my data ever sit on your infrastructure, even temporarily?

2. What access do you need into my storage, and is it inbound or outbound-only?

3. Does this only work with cloud storage, or can it use on-prem systems too?

The honest answers will sort the three flavors above faster than any feature comparison page.

We’re building sftp.cloud to answer all three of those questions the way we think they should be answered. We just opened up early access to the first 100 people who want in: reserve your spot at sftp.cloud. Prefer to just keep an eye on things for now? Subscribe to this blog instead.

What’s changed?

• Fixed a bug in our Google Cloud Storage VFS implementation that prevented certain file-transfer clients from correctly unmarshalling directory names

• Added CtxVFSName() and EventCtx() to the SyncJS scripting engine

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Added support for Passkey sign-in to all UIs (SuperAdmin, Admin, and of course WebClient!) to include yet another strong authentication mechanism to the already rich set supported by Syncplify Server!

  

• Page-wide drop-zone to upload files and folders with a more modern user experience similar to Google Drive, OneDrive, etc… just drop the items you want to upload anywhere and they’ll be uploaded into the current directory displayed in your WebClient! UI at that time

  

• Fixed a compatibility issue in our OIDC implementation that prevented login completion when connected to Microsoft Entra ID (note: all other OIDC providers were already working well, this issue was exclusively related to the way the optional “alg” claim is handled, which Entra ID does differently from any other OpenID Connect IdP)

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

These are not just UX gimmicks, they genuinely help you keep your account safe, especially the passkeys, which are our most highly recommended login method going forward.

So, how do you enable those features?

First of all, perform a normal/legacy login with your current credentials. Once you’re logged in, click the Account settings menu item in the left sidebar.

Once you are in your account settings page, click on the Sign-in methods button in the top-right corner of the page:

You will be forwarded to this page:

From there you can:

• change your password (always make sure you have a strong password regardless of what sign-in method you actually use)

• add/rename/remove passkeys (arguably the safest sign-in method)

• connect/disconnect your social logins (security depends on how safely you have them locked down, but they’re usually pretty safe)

We strongly encourage each and every one of our customers to adopt passkeys whenever possible, or at least connect one of their social accounts that are already protected by their providers’ authenticator apps, and use that account to sign-in from there on.

Thank you all for helping us keep your customer accounts safe.

What’s changed?

• Improved accessibility (WCAG 2.2 AA) and usability (UX) of the WebClient! UI with a small set of targeted optimizations

• Added an all-new CtxRelTargetPath() to our scripting engine, specifically designed to retrieve the destination (target) relative-path inside of the AfterFileRename event-handler

• Backups taken from nodes that used to be part of an HA cluster and then they left and went back to being stand-alone single servers now no longer contain legacy HA node bindings

• Usual small set of little bug-fixes and quality of life improvements

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

It’s available exclusively with the Ultimate license tier, and if you’re running one, it’s already there waiting for you.

What it is

Sixteen built-in operational reports, accessible directly from the Admin UI. Print them, download them, export them to JSON/CSV for further analysis, or just read them on screen. Every report is generated on demand from live data, so what you see reflects the actual state of your environment at the moment you run it.

The reports span several domains, including (but not limited to) operations, compliance, and security. And more will be added in future updates.

Why it matters more than it looks

Here’s the thing about enterprise file transfer environments: they accumulate. Users get created and forgotten. Permissions get granted and never revisited. Accounts that were set up for a partner integration three years ago are still sitting there, idle, with elevated access to production directories.

Nobody meant for that to happen. It just did, incrementally, across hundreds of small decisions that were each perfectly reasonable at the time.

Compliance audits and security reviews surface these problems, but only after the fact, and usually in the most stressful possible context. Enterprise Reporting gives you the visibility to catch them on your own schedule, before anyone asks.

Just two of the many possible examples that illustrate this well.

Inactive users shows every account that hasn’t logged in for 90 or more days, with a last-login timestamp and a total login count. That login count matters: an account with hundreds of historical logins that has gone silent for three months is a different conversation than a test account someone created and never used. Both are worth reviewing. Now you can see both at a glance, any time you want.

Elevated access shows which users have been granted permissions beyond the default, on which mount points, and against which Virtual File Systems. Delete directory. Delete files. Create symlinks. Each permission is listed individually per user, per path. If you’ve never run a report like this in your environment, the result may surprise you.

Not just for auditors

It’s tempting to think of compliance reporting as something you pull out when someone asks for it. A checkbox exercise.

The more useful mental model is operational hygiene. Inactive accounts expand your attack surface. Excessive permissions increase the blast radius of any compromised credential. Neither of these is a theoretical risk in environments moving sensitive business data over SFTP. Both are problems you can actually see and act on, now, without waiting for an external audit to tell you they exist.

That’s what this module is for.

All 16 reports, with more to come

The current release includes 16 built-in reports, here’s a list grouped by category.

Access & Identity

• VFS by user

• Users by VFS

• User inventory

• Authentication & MFS

• Inactive users

• Failed sign-ins

• Elevated access

Security & Compliance

• Blocklist

• Certificates & keys

• Security posture

• Shared objects

Storage

• Storage inventory

Activity

• User statistics

• Traffic & sessions

• Unused app-passwords

Automation

• Automation inventory

Future updates will add to that list. If there’s a specific report type that would be useful in your environment, reach out. We listen.

What’s changed?

• Adopted the new UI visual language that is now being implemented into all Syncplify software products to unify all UIs onto the company’s new official brand identity

• Also updated the Go compiler and standard library, which in turn includes the usual number of small bug-fixes here and there

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Adopted the new UI visual language that is now being implemented into all Syncplify software products to unify all UIs onto the company’s new official brand identity

• A bug that prevented parametric VFSs (coming in from the Syncplify Server! side) from auto-creating their folder has been fixed

• Also updated the Go compiler and standard library, which in turn includes the usual number of small bug-fixes here and there

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

We want to be upfront with you about what this release is, because it is not a typical point release.

V8.0.0 was a backend story: a rebuilt HA subsystem, containerization, OIDC, i18n, ACID transactions. Dense, foundational, deliberately non-glamorous. We shipped it, and we shipped it clean. What we held back, intentionally, was something that deserved its own release and its own announcement: a complete ground-up redesign of every user interface in the product.

What’s changed?

• All-new SuperAdmin UI. Not a refresh or a polish pass. A complete redesign, built from scratch with a clean design language, consistent information architecture, and a substantially reduced learning curve for new administrators.

• All-new Admin UI. Same philosophy. Every screen reconsidered, every workflow examined for friction and redesigned. If you have been using the Admin UI for years, expect to be surprised. In a good way.

• All-new WebClient! UI. Rebuilt from the ground up to be faster, cleaner, and immediately intuitive to end users who have never touched a file transfer product before.

• Accessibility as a first-class requirement. This is the main reason these UIs had to be rebuilt rather than revised. Our customer base has grown to include government entities and large regulated enterprises for whom accessibility compliance is not optional, it is legally mandated. Bolt-on accessibility does not work, and we refuse to ship it. The only path to genuine WCAG compliance was a clean start, so that is what we did.

• UX, reconsidered entirely. Five years of incremental additions had left our previous interfaces carrying debt we could no longer responsibly ignore. The new UIs are not just more accessible, they are more consistent, more predictable, and frankly more pleasant to use on an every-day basis.

• Mobile friendliness as a non-negotiable requirement. All of our UIs are now designed and optimized to be usable on (and auto-adapt to) desktop as well as mobile devices. We call this approach “desktop-first, mobile-excellent”.

• The usual collection of bug fixes, because no release ships without us having hunted down everything we could find.

Please make sure you read the upgrade instructions carefully. As always, you can download the most recent release from our website.

Here’s what’s new.

What’s changed?

• Containerization support. For the first time in Syncplify Server!’s history, you can run it in Docker, Kubernetes, Portainer, or any OCI-compatible container runtime. This has been one of the most requested capabilities over the years, and V8 delivers it properly.

• All-new High Availability subsystem. The HA architecture has been rewritten from the ground up. Performance and resilience are orders of magnitude ahead of any previous HA implementation, and for the first time the product ships with a full, genuinely elegant observability stack so you can actually see what your cluster is doing.

• OIDC support with app-passwords. Full OpenID Connect integration, with individual configurations per Virtual Site (SuperAdmin, Admin, and User tiers each have their own settings). App-passwords ensure that legacy protocol clients continue to work seamlessly alongside modern SSO flows.

• Internationalization (i18n). A genuinely large effort, and one we’re particularly proud of. V8 ships with full UI localization in English, German, French, Spanish, Italian, Chinese, Japanese, and Korean, with more languages on the way.

• Custom HTTP headers. You can now define custom HTTP response headers for the Admin UI, SuperAdmin UI, and WebClient! UI independently, giving you fine-grained control over security posture and compliance requirements.

• Backed by SyngoDB with true ACID transactions and compound indices. The underlying database engine has been significantly upgraded, bringing true multi-document ACID transactions and compound index support that underpins the reliability of everything built on top of it.

• Improved visuals and UX across all interfaces. Every UI in the product, Setup, SuperAdmin, Admin, and WebClient!, has received a meaningful refresh, particularly with regards to accessibility and user experience. The changes are evolutionary rather than disruptive, but the cumulative effect is noticeable.

• The usual collection of bug fixes, because no release ships without us having hunted down everything we could find.

Please make sure you read the upgrade instructions carefully. As always, you can download the most recent release from our website.

Thank you for trusting our software with your secure file transfers. V8 is something we’re genuinely proud of, and we hope you find it worth the wait.

What’s changed?

• Updated the Go compiler and standard library to the most recent version, which comes with its own internal small bug fixes

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Updated the Go compiler and standard library to the most recent version, which comes with its own internal small bug fixes

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Start with the question every security review eventually asks: where is the attack surface, and who owns it?

In the standard managed-file-transfer SaaS model, the answer is uncomfortable. Your files sit at-rest on the vendor’s infrastructure, and your endpoint is reachable because something inbound is exposed: a listening port, a NAT rule, a hole punched in the DMZ. You outsourced your file transfer and inherited two attack surfaces you don’t control: the vendor’s storage, and your own inbound exposure.

SFTP.cloud removes both. Not hardens. Removes.

The inverted data plane. Public clients (SFTP, FTPS, FTPES, HTTPS) connect to a highly available protocol edge in our cloud. That edge terminates the protocol and relays the bytes. It does not store them. A lightweight connector you deploy on or next to your own storage opens an outbound connection to that edge, and traffic flows back through it to where your files actually live: your subnet, your disks, your keys. The cloud sees an encrypted data stream. It never sees a file-system. NO CUSTOMER FILES HERE isn’t a policy we promise to honor, it’s a property of the design.

The two-fold inverted control plane. The same inversion applies to management. Your credentials, your access policies, your service configuration: none of it lives in our cloud either. Your control nodes connect outbound to the management layer; the management layer never reaches in. There is no inbound admin endpoint on your side to discover, scan, phish, or brute-force. There is no door to knock on.

Now add it all up the way a CTO has to:

• Inbound firewall rules required: zero. No NAT, no port forwarding, no DMZ. The connector dials out; nothing dials in.

• Customer files in the vendor cloud: zero. Your files stay in your storage subnet, under your control.

• Blast radius of a cloud-side compromise: a stateless protocol relay with no files and no standing inbound path to your network. Nothing to steal, and nowhere to pivot.

• Data residency: trivially answered, because the answer never changed. Your files never left your subnet.

We’ll say the rest plainly, because the category won’t: most “secure” cloud file transfer is really just secure storage of your files on someone else’s servers. We think that’s the wrong default. An attack surface you don’t have can’t be breached. And a file we never hold can’t be leaked.

For the record, SFTP.cloud remains an entirely new product, not a replacement for Syncplify Server!, R2FS!, or AFT!. It’s built for teams that need an internet-facing, fully managed endpoint without surrendering custody of their data to get one.

Release date is still under wraps. The connector deployment model, architecture deep-dives, and early-access details are coming. Subscribe, and we’ll post here first.

But here’s the honest truth we’ve been sitting with as we’ve grown: security is the floor, not the ceiling, of what “enterprise-grade” actually means.

Enterprise-grade means your platform works for your teams in Tokyo, your partners in Berlin, your clients in Milan, and your auditors in Seoul, all without forcing everyone to navigate a UI that was built for English speakers only. It means the software respects the user, not just the perimeter.

And that’s precisely why V8 will be the first truly multilingual version of our software. On day one of release, the UI will ship fully localized in eight languages:

🇺🇸 English
🇫🇷 French
🇩🇪 German
🇮🇹 Italian
🇪🇸 Spanish
🇨🇳 Chinese (Simplified)
🇯🇵 Japanese
🇰🇷 Korean

This isn’t a translation layer bolted on at the last minute. Internationalization (i18n) was built into V8’s architecture from the ground up, which means additional languages can be added in subsequent releases without touching core functionality. It also means that each user can override the server’s default language just for themselves based on their preference, without affecting other users.

More languages are already on the roadmap.

The security story hasn’t changed. The zero-CVE record, the zero-breach history, the architecture that Fortune 500 security teams trust, all of that carries forward into V8. What’s new is the recognition that the organizations deploying our software are global, and their users deserve a product that reflects that.

V8 is coming soon. Stay tuned.

Since then, several of you have asked what the backend of something like sftp.cloud actually runs on. Connector registration, session routing, access policy distribution, audit records, configuration replication across geographically dispersed nodes. That is a lot of operational state that must stay available, consistent, and survivable across node failures, regional outages, and network partitions.

SyngoDB is our embedded document database. It backs Syncplify Server!, R2FS!, and AFT!, handling configuration, metadata, and operational state reliably and fast. It supports optional RAFT-backed replication for multi-node deployment.

But sftp.cloud is a different beast.

RAFT is a CP system. Under a partition, the minority side stops accepting writes. In a single-datacenter cluster, that trade-off is entirely reasonable. But when your nodes are spread across multiple regions, “wait for a majority” imposes real write latency on a healthy cluster, and an isolated region stops accepting writes entirely until the partition heals.

That is not the operational model sftp.cloud requires.

Introducing GeoSyngoDB

GeoSyngoDB is the AP-first distributed document database that we designed and developed to power sftp.cloud.

AP-first is not a euphemism. Under the CAP theorem you cannot have Consistency, Availability, and Partition tolerance simultaneously. We deliberately chose Availability and Partition tolerance over global real-time Consistency. Reads and writes succeed on any healthy, reachable node even during a partition failure. The cluster converges to consistency once the partition heals. For sftp.cloud’s operational data model, that trade-off is correct.

Data is distributed across nodes using a token ring with no leader and no single coordinator. Writes go to a configurable number of replica nodes, selected from a topology-aware preference list that tracks each node’s datacenter, region, and VLAN, spreading replicas across failure domains before falling back to same-location nodes. When a replica is temporarily unreachable, its mutations are delivered once the node recovers. Background anti-entropy workers and passive read-repair keep replicas converging continuously after failures, re-partitioning, and topology changes. Membership is gossip-based: nodes discover and monitor each other without editing configuration files on every peer.

The icing on the cake? The local storage engine underneath all of this is still an embedded SyngoDB. GeoSyngoDB does not reinvent its document storage, indexing, or compaction. It delegates all of that to the same layer that backs our other products, keeping the physical storage layout clean and the I/O paths separate per namespace.

What it means for you as an sftp.cloud user

The infrastructure behind sftp.cloud’s control plane runs on a purpose-built, geographically distributed document store that we understand completely, because we wrote every line of it for this exact workload.

Session metadata, connector registry, access policies, and audit records live in a system that stays available through regional outages and network partitions, converges automatically after failures, and has no single point of failure anywhere in its data plane. No third-party SaaS database in the critical path. No opaque failure modes. No service agreement as a load-bearing architectural dependency.

sftp.cloud is not finished. But when it ships, the database layer underneath it will have been designed, built, tested, and benchmarked specifically for this workload.

Not borrowed. Not vibe-coded. Not bolted in. Built.

What’s changed?

• Fixed a small bug in the SftpClient object that was causing the DeleteSourceAfterDownload to fail in some specific circumstances.

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

We’ve never liked with that model. So we’ve built an alternative.

sftp.cloud is a managed SFTP, FTPS, FTPES, and HTTPS file transfer service, with a web client and full secure file sharing capabilities. But its architecture works differently from everything else in this space, in a few ways that matter.

Your files are never stored in our cloud. Not during transfers, not at rest, not ever. The cloud component is a protocol relay, not a storage destination. You deploy a lightweight connector on or next to your own storage servers, it opens an outbound connection to the cloud, and from that point forward your on-premises storage has a fully managed, highly available SFTP endpoint on the internet, without a single inbound firewall rule required on your end.

No NAT. No port forwarding. No DMZ gymnastics. Just an outbound connection from your side, and a professional-grade file transfer service facing the world.

The control plane follows the same principle. Your sftp.cloud configuration, your user credentials, your access policies, and - above all - your files: none of it lives in our cloud. Your control nodes connect outbound to the management layer, not the other way around. There is no “doorbell” on your on-prem nodes for anyone to ring, because there is no door. Not a locked one. Not a hidden one. The attack surface simply does not exist.

We’re calling this an inverted control plane. It’s the first time this architecture has been applied to a cloud SFTP SaaS, and we think once you see how it works, you’ll find it difficult to settle for anything less.

One thing worth saying clearly: sftp.cloud is not a replacement for Syncplify Server!, R2FS!, or AFT!. Those products aren't going anywhere, and neither is our commitment to them. sftp.cloud is an entirely new product, built for a different set of use cases, specifically the organizations that need a managed, internet-facing file transfer endpoint without the overhead of running and maintaining their own server infrastructure, yet refuse to surrender control of their data to do it.

More detail on the architecture, the connector deployment model, and everything else is coming soon. If you want to be among the first to know when sftp.cloud opens for early access, subscribe to this blog. We’ll post here first.