kdmtctl

Proxmox is QEMU, but with GUI and lot of infra stuff.

It could be true. But pearls are rare and storage is expensive.

For each session. Keys are rotated frequently, so a lot of noise could be produced. The only and one address is a good strategy for anti fingerprint though, but it is not easy to achieve for WG tunnels and pure L3 routing.

Personally I don't really get their multi hop when you connect on a predefined port on an ingress server to get redirected to egress in a different region. Easy guessable for a powerful observer.

Anyway any VPN is only an encryption tool, not an anonymizer.

They provide white label for Mozilla, Tailscale and may be some others I am not aware of. Plus they really sell a lot of subscriptions.

To do what? Replay? Just curious on an attack vector.

There are lot more said in the comment I answered. Nothing happened for China, to be precise. A lot of wishful thinking only.

A little bit exaggerated. Nothing really happened yet.

I suspect there is acsolid corpus of advices online that mention the exposed ports risk. Alongside with flawed examples you mentioned. Narrow request will trigger the right response. That's why LLMs are still requiring basic understanding of what exactly you plan to achieve.

One could pretend that beans are intentionally burned, "The Vietnamese Way", regardless of the source material quality. Lighter roast would differ from batch to batch with varying not-so-good taste, but charcoal is always a charcoal.

You’re right. Missed it while scrolling. Regarding the parent discussion, a classic statement is also two-sided. So, you need to collect sources (debit) and destinations (credit).

It is definitely possible to make each side of transaction a different record, but you have to link them, so there would be another ID for a transaction to group later. It is always there in any case, but you are either joining while getting a balance or grouping while reconstructing transactions for reports. So, it depends on the primary load: lots of transactions to register or lots of reports to provide. Both are used.

A single bank payment for two outstanding invoices to a single entity or two different entities? In the later case there should be different accounts credited. Technically it is possible to account, but a bank should obey the accounting practices and generate multiple transactions on different accounts. The higher level document could be atomic indeed, so it either registers as a batch or not registers at all.

It is not a redundancy. Actually the meaning of a transaction encoded in a pair of accounts. You will need to store it somewhere anyway in a real world scenario, but predefined account pairs is the universal language. The accounting system.

"Debit" is a verb here.

An account could be only on one side. The side and chapter is the meaning of this account. Account on the left just negates the increase/decrease direction.

In a bank ledger when a loan appears on a checking account, both increased. Loan on the left, checking on the right. DT Loan → CT Checking. Loan is an asset for a bank, Clients money is a liability.

On a client's balance sheet everything is mirrored. Checking is an asset, Loan is a liability.

Queries are quite simple. Volumes are problematic. In a big institution you would find several ledgers included in the general ledger by totals. You just don't need all the details in one place.

Money can't appear and disappear. There should be always a destination. It helps accounting a lot. If someone owes anyone, liabilities increases (active/passive accounts), but this liability is spent somehow, which could become an asset (Goods Purchased using a Loan), so you can track all the chain through account statements.

Destination is the key. You can't just arbitrarily change an account balance using a transaction in a ledger. There should be a destination and this the second record.

This what GAAP, IFRS and even all the Basels for banks describe in strict detail. But every accounting system and practice is based on double entry and not just keeps the balance sheet consistent but adds a meaning to every transaction using predefined types of accounts.

There are no 3 leg transactions in a ledger. You described an order. Ledger transactions is one layer deeper. Order creates 2 different transactions: Payment correspond to payments accounts, taxes to the Taxes Payable. That is how classic bookkeeping works.

Exactly. Any proper ledger is a transaction log. Balances and turnovers are calculated, not stored. I've seen a lot of attempts to 'cache balances', and this was always the point where anything could go wrong.

I used a Reolink Argus with a battery and Wi-Fi connection. The one I used is probably EOL now, but a quick look at the site shows even solar chargeable options. So, it is possible.

Reinsurance is a beast. I spent a good time cracking layers and trying to implement the logic with a team.

There should be a system analyst. Every ERP or core banking big name works this way. Requirements have to be processed and then passed for implementation. In an agile setup rinse and repeat. As a side effect the whole team gains the domain knowledge. Or part of it.

This. Ledgers are a domain knowledge. Anything else should be built on top, including high load optimizations.

I've seen a lot of ledgers. Crypto is much more complicated.

In the end of the day you provide a full stack or just do UI/marketing. This is a good old vertical integration dilemma.

You can't avoid this. It is either your client or bank's client. And no bank will take the burden to account every $0.2 transaction for you, spending its own computing power. It just a quite expensive thing to do. That is why banks often separate the main ledger and retail ledger[s]. Each system tuned for a different performance profile.

You should've asked it to sketch it for you.

E2EE is optional on Telegram and not really convenient. You can create a private chat which will be E2E encrypted but this takes a few taps and pins to device. Most of the users don't bother. And the main target is not personal chats but channels which can be easily discovered and followed.

This is not an e2e battle, this is the hunt for channel owners. Frankly it is too easy to make a "local chat" and sell stuff. Durov has the data and this is his weakness and strength. Platform is viral but there are too much for one hands.

Telegram does store chats and channels on servers. Signal doesn't. I wonder Durov managed to stay between Scylla and Charybdis that long.

Indeed. It was widespread by the "cooperative" movement and the first fast food was shashlyki (even before the fall) and khachapuri. South Caucasus people were the first who started with food and flower markets. So the cuisine.

It is a technical limitation. Depends on number of shared downstream and upstream channels in a given network.

It was basically the same across the Soviet Block. Used to grow in a former USSR republic and did exactly this.