Tela Network

Posts by Sam Gödel-Conway

Showing posts 1-10 of 22 (most recent first)

#110 | 2026-03-12 08:17:43 UTC
0 replies

An interesting demographic strategy: / Moroccan families pool resources to facilitate hrraga (illegal crossers) specifically for their most problematic members. The family calculus is brutal and rational. That cousin with addiction issues who brings hschuma (shame) to the family? Pool money from uncles, aunts, and grandparents to pay a smuggler. That nephew with a criminal record who cannot find work and sits unemployed bringing disgrace? Finance his boat crossing to Spain. The binary outcome serves family interests either way: he dies attempting the Strait of Gibraltar crossing (problem eliminated, family can claim tragedy rather than disgrace), or he reaches Spain and eventually sends remittances (problem exported, potential income stream created, family honor preserved). / Morocco reduces domestic crime, increases remittances (7-8% of GDP), and exports social problems to Europe. / https://asmium.substack.com/p/on-muslim-immigration-to-europe

#102 | 2026-02-03 08:17:50 UTC
0 replies

Reader: When users perform a gated action on a web platform, how is it easier to charge them after the fact? Surely this still requires a ledger. - It's easier because you can treat each gated action as a simple counter increment. At the end of a period (e.g. monthly), you bill for the total. Instead of a financial transaction per action, you have one transaction per period. Over time you may log counter increments in more detail, perhaps approaching ledger-like tracking. But you don't have to start with it. It's also psychologically easier for a user to click now and pay later. This is fine for utilities like hosting: you buy a service, get an invoice later. On current social platforms, posts are free, so no tracking needed, but - endless noise. If you want a real pro-human social platform, this doesn't work. Users and bots can create throwaway accounts, post junk, and never pay. But their content stays on the system and consumes the attention of current and future users.

#97 | 2026-01-17 11:56:22 UTC
0 replies

Chat Excerpt: --- 20th century - mass media, mass gov fiat currency, advantage hard-left. The Nazis count as surprisingly hard-left, economically speaking. 21st century - post drones & blockchain, looking like it will be advantage hard-right. these days, large mass of “the people” == big easy target for deniable remote weapons average man is no longer a threat (as he was in 20th century). Both nazi and marxist rely on gathering together average man to achieve power. Therefore in 21st century neither strategy will work. The flavour might be used for rhetorical purposes. Major issue is: relatively few people will have power, and popular discontent won't have much effect except for stochastic terrorism. So more like blade runner 2049. I mention drones because they would seem in future to be an advantage for the few as opposed to the many. I'm basically betting on a trend line of "average man will matter even less in future than he does now". ---

#86 | 2025-12-01 06:41:19 UTC
1 reply
Sam Gödel-Conway
Reader: When users perform a gated action on a web platform, how is it easier …

"Today, if you don’t want to build your own ledger, you do have a few options. For example, there are hosted services like Modern Treasury and ledger-specific databases like TigerBeetle. Both of these are impressive and probably a good fit for many. But by using a ledger outside of the main application database, you lose transactionality and atomicity. Namely, you have to worry about orchestrating two systems that can fail independently. What happens if you write your main data, but the ledger update fails? Or the ledger operation succeeds but your app hits an error and fails to write the surrounding data. Integrating with these often requires two-phase commits and other strategies to ensure they stay in sync. And when they fall out of sync, it can be very hard to debug." https://www.pgrs.net/2025/03/24/pgledger-ledger-implementation-in-postgresql

#76 | 2025-11-06 09:52:45 UTC
1 reply
Sam Gödel-Conway
"Today, if you don’t want to build your own ledger, you do have a few …

Reader: How difficult is it to build an internal ledger system? My impression is that you are discounting that as an option, but I have no feel for how hard it might be to do. - Fairly difficult. A double-entry ledger system is a complex piece of equipment. Building one requires knowledge of both bookkeeping and software. Maintaining software is costly, and the costs increase with time. Code grows to support many user actions, data pathways, dependency versions, and external APIs. Future changes must attempt to add new capability without breaking an ever-larger number of existing features. The goal of an experienced software developer is to write relatively little code, and for that code be as meaningful as possible. So: When faced with the prospect of learning how to build and maintain a complex component, the experienced developer hesitates, and looks for existing solutions first. I'll keep looking for a while. However, atm, it does seem that I will have to build it myself.

#73 | 2025-11-02 09:18:47 UTC
1 reply
Sam Gödel-Conway
Reader: How difficult is it to build an internal ledger system? My impression is that …

Goal: Gate user actions (e.g. make a post) based on payment of a token. This is a much larger problem than it seems. Naive idea: User buys credits, check user balance, subtract a token before allowing a post. But: You have to track payments in and credits out in order to keep balances correct. So you need a ledger. A single-entry ledger will break when you encounter double-spending, retries, refunds, and audits. So you need a double-entry ledger. I have looked at outsourcing this. But offering complex custom bookkeeping software to non-enterprise customers is a structurally bad business. Also, your app must make an external API call on every gated user action. This indicates that you need to build and maintain an internal double-entry ledger system. This is why most apps: 1) Charge a subscription or 2) Charge for usage afterwards (no real-time gate) But neither of these models produce the user experience incentives that I think are required for a good version of the future.

#67 | 2025-10-06 14:12:58 UTC
0 replies

" This truth is only available to the most advanced atheists and the most advanced Christians. The advanced atheist has purged himself of all traces of folk religion, and understands the world as it is - an infinitely cold universe of protons and electrons, whose fundamental rules are a few lines of mathematics with no concept of humanity. Our galaxy is not even special, let alone our planet. To the advanced Christian, God’s will is just as cold and his justice is just as inexorable, and evil is sent to punish evil. Maistre read the French Revolution as God’s punishment of the decadent liberals who brought it about, and the weak conservatives who failed in their duty to oppose it. Was he wrong? I love my protons and electrons, but I can’t see how he was wrong. " https://graymirror.substack.com/p/you-cant-handle-the-truth

#57 | 2025-09-09 11:18:22 UTC
0 replies

Parsons, who was from Pasadena, California, was an engineering genius who played a central role in the invention of space rockets. He co-founded the Jet Propulsion Laboratory. ... Parsons didn't get to see [the Moon landing]: he blew himself up at home in an accident with rocket fuel in 1952, aged 37 (a crater on the moon is named after him). He was a great innovator; he was also an epic crank. During his early work with rockets he was taking a lot of drugs and participating in a polyamorous devil-worshipping cult. He later became a devotee of the English occultist Aleister Crowley, and a key member of Crowley’s group in the US. After the war he became close to a former naval officer called L. Ron Hubbard, with whom he took part in a series of magical rituals aimed at manifesting the goddess Babalon. (Hubbard borrowed all his money, and his wife, and ran off with both, before founding Scientology.) [1] https://www.ian-leslie.com/p/rationalist-cults-of-silicon-valley

#54 | 2025-08-26 07:07:47 UTC
0 replies

The current meta for social platforms selects for platforms that optimize for emotional engagement. The core mechanic is "reaction", as reified in likes, shares, comments. Posts are simply the raw material. Reaction is what keeps people coming back. Humans have a powerful anxiety-driven need to perceive the social currents - "what are other people saying about X ?" (what should my opinion be ?) Reaction maintains regular engagement, which allows the business of adverts to exist. I propose a new core mechanic: Validation. A person's social profile would showcase the posts that they have validated - verifiable record of what they judged to be true / insightful / useful. The value proposition: That this profile would increase the user's professional reputation. The overall result: The platform produces few posts, but each post supports a cloud of confirmations. Highly-validated posts are then republished on existing platforms, with the validators featured alongside the author.

Validated by

StJohn Piano 30 Aug 2025

Reposted on

🏷 LinkedIn 30 Aug 2025
#53 | 2025-08-22 06:22:29 UTC
0 replies

MVC (Model-View-Controller) is a pattern in software design for building user interfaces. Key benefit: It keeps code modular - models don't deal with presentation, and views don't contain business rules. 1. The model defines what data the app should contain. 2. The view defines how the app's data should be displayed. 3. The controller contains logic that updates the model and/or view in response to input from the users of the app. Scenario: A user writes a new post on an online forum. - Model: Receives and validates the post data. Handles saving to and loading from the database. - View: Builds the page shown to the user. Either the "New Post" form with validation errors, or the "Post Details" page showing the freshly created post. - Controller: Handles the "create post" request. Flow: - User makes post - Controller receives post data - Model saves to database - Controller chooses a View - User sees result