@ daa41bed:88f54153

There has been a good bit of discussion on Nostr over the past few days about the merits of zaps as a method of engaging with notes, so after writing a rather lengthy [article on the pros of a strategic Bitcoin reserve](https://geek.npub.pro/post/dxqkgnjplttkvetprg8ox/), I wanted to take some time to chime in on the much more fun topic of digital engagement. Let's begin by defining a couple of things: **Nostr** is a decentralized, censorship-resistance protocol whose current biggest use case is social media (think Twitter/X). Instead of relying on company servers, it relies on relays that anyone can spin up and own their own content. Its use cases are much bigger, though, and this article is hosted on my own relay, using my own Nostr relay as an example. **Zap** is a tip or donation denominated in sats (small units of Bitcoin) sent from one user to another. This is generally done directly over the Lightning Network but is increasingly using Cashu tokens. For the sake of this discussion, how you transmit/receive zaps will be irrelevant, so don't worry if you don't know what [Lightning](https://lightning.network/) or [Cashu](https://cashu.space/) are. If we look at how users engage with posts and follows/followers on platforms like Twitter, Facebook, etc., it becomes evident that traditional social media thrives on engagement farming. The more outrageous a post, the more likely it will get a reaction. We see a version of this on more visual social platforms like YouTube and TikTok that use carefully crafted thumbnail images to grab the user's attention to click the video. If you'd like to dive deep into the psychology and science behind social media engagement, let me know, and I'd be happy to follow up with another article. In this user engagement model, a user is given the option to comment or like the original post, or share it among their followers to increase its signal. They receive no value from engaging with the content aside from the dopamine hit of the original experience or having their comment liked back by whatever influencer they provide value to. Ad revenue flows to the content creator. Clout flows to the content creator. Sales revenue from merch and content placement flows to the content creator. We call this a linear economy -- the idea that resources get created, used up, then thrown away. Users create content and farm as much engagement as possible, then the content is forgotten within a few hours as they move on to the next piece of content to be farmed. What if there were a simple way to give value back to those who engage with your content? By implementing some value-for-value model -- a circular economy. Enter zaps.  Unlike traditional social media platforms, Nostr does not actively use algorithms to determine what content is popular, nor does it push content created for active user engagement to the top of a user's timeline. Yes, there are "trending" and "most zapped" timelines that users can choose to use as their default, but these use relatively straightforward engagement metrics to rank posts for these timelines. That is not to say that we may not see clients actively seeking to refine timeline algorithms for specific metrics. Still, the beauty of having an open protocol with media that is controlled solely by its users is that users who begin to see their timeline gamed towards specific algorithms can choose to move to another client, and for those who are more tech-savvy, they can opt to run their own relays or create their own clients with personalized algorithms and web of trust scoring systems. Zaps enable the means to create a new type of social media economy in which creators can earn for creating content and users can earn by actively engaging with it. Like and reposting content is relatively frictionless and costs nothing but a simple button tap. Zaps provide active engagement because they signal to your followers and those of the content creator that this post has genuine value, quite literally in the form of money—sats.  I have seen some comments on Nostr claiming that removing likes and reactions is for wealthy people who can afford to send zaps and that the majority of people in the US and around the world do not have the time or money to zap because they have better things to spend their money like feeding their families and paying their bills. While at face value, these may seem like valid arguments, they, unfortunately, represent the brainwashed, defeatist attitude that our current economic (and, by extension, social media) systems aim to instill in all of us to continue extracting value from our lives. Imagine now, if those people dedicating their own time (time = money) to mine pity points on social media would instead spend that time with genuine value creation by posting content that is meaningful to cultural discussions. Imagine if, instead of complaining that their posts get no zaps and going on a tirade about how much of a victim they are, they would empower themselves to take control of their content and give value back to the world; where would that leave us? How much value could be created on a nascent platform such as Nostr, and how quickly could it overtake other platforms? Other users argue about user experience and that additional friction (i.e., zaps) leads to lower engagement, as proven by decades of studies on user interaction. While the added friction may turn some users away, does that necessarily provide less value? I argue quite the opposite. You haven't made a few sats from zaps with your content? Can't afford to send some sats to a wallet for zapping? How about using the most excellent available resource and spending 10 seconds of your time to leave a comment? Likes and reactions are valueless transactions. Social media's real value derives from providing monetary compensation and actively engaging in a conversation with posts you find interesting or thought-provoking. Remember when humans thrived on conversation and discussion for entertainment instead of simply being an onlooker of someone else's life? If you've made it this far, my only request is this: try only zapping and commenting as a method of engagement for two weeks. Sure, you may end up liking a post here and there, but be more mindful of how you interact with the world and break yourself from blind instinct. You'll thank me later. 

@ df478568:2a951e67

Freedom tech is free and open-source software. It is free as in freedom. A common license in FOSS is the MIT license. It's the license behind Bitcoin, a peer-to-peer electronic cash system. Anyone is free to run this software. The same is true for the software at mempool.space. The software is free to use. I run it on my own server. This is what I use to time-stamp my articles. You can use it to check transactions on the bitcoin time chain, but you need to trust that I'm not doing any funny business. I'm not, but keep in mind, the whole point of p2p elwctronic cash is that you don't trust. You verify. The beauty of FOSS is: You don't need to trust me. You can triple-check the transactions you search on my mempool instance by looking at the official mempool.space website and blockchain.info...Or...You can run your own node on your own hardware, free of charge. Of course, the hardware is not free. Neither is the actual bitcoin. The freedom is built into the software, but as the saying goes, "freedom isn't free." It took me years to learn how to run my own software on my own server and make it available on the clear net. ## SearXNG  [SearXNG](https://github.com/searxng/searxng) is my favorite search engine. I don't like giving up my precious data to big tech located in the United States or China. I run my own search engine. I have noticed certain biases in Google searches. The biggest problem is ads. Companies tend to pay for Yelp and Google reviews. I called an AC company I found from a local magazine that came in the mail. A portly man wearing an HVAC costume drove to my house in a white van. He had a great smile and even better social skills. The van had a slogan plastered on it like most tradie vans do. "Reviews Matter We have a 4.9 Review on Google." He also had his name painted on this van like a Bomber pilot from WW2. I won't dox him, but it was something like "Joe the closer." I don't trust the omnipotenence of the Googs. I also don't trust fat men they call "the closer" to give me the best deal. The trick to saving sats is to choose the game-theory optimal way of negogiation. In DUCY, by David Sklansky, I learned useful negotiation skills. Sklansky wrote classic poker books and applied his actuarial math brain to negotiation techniques. He said he would go to a Toyota dealer and say, "I'm shopping for a new Camry. I already have a price from dealership XYZ in a nearby city. What is your price?" This changes the dynamic right from the starting line and gives the consumer the advantage. So I tried this based technique with the HVAC industrial complex. I got a quote from 3 people: 1. Joe "The Closer." 2. The Costco-sponsored HVAC Company 3. My SearXNG search results. In essence, I apply the same logic I learned running a full bitcoin node. Remember how I said the decentralized nature of bitcoin allows you to **triple-check your transactions?** Running SearXNG allows me to triple check my search results in a similar fashion. I don't trust Google, Costco, or the magazine I get every month in the mail. I verify results with my own search engine. My SearXNG does not track my location, but I set it to give me local results. To be honest, I have not verified this, but the code is on GitHub for everyone to see. I don't want to be "sold" on an AC. I don't want an AC if I could avoid it, but my AC was as dead as dentacoin. Living in Southern California with a wife going through "the change" gave me no alternative. The guy I found on SearXNG showed up in an unmarked van. He had a beard. He was not "a closer." He was an actual HVAC technician. He tried cleaning my unit made in the same year Weezer released their Blue album. He said he coukd jerry rig it to get it working for another few months, but the machine is on it's last days. He said a newer unit would also be more efficient so I asked him about the energy like a bitcoiner. "How many kilowatt hours does it cost me to run my AC versus a new AC?" I don't remember the exact answer, but I asked all three companies. He was the only one that new how to find out. He also happened to be the cheapest, but I would have bought a new AC from this guy even if he wasn't. I told him I made a space heater out of a bitcoin miner. He had no idea this was possible, but he at least pretended to find it interesting. That's why I use SearXNG to find tradesmen. It's better than Yelp. If you would like to try my instance of SearXNG, check it out. `523FeCpi9Gx4nR9NmSFIMEaYcI5Q4WmhYHPEPaEah84=` To decrypt it, use the key behind the paywall at: https://8gwifi.org/CipherFunctions.jsp npub1marc26z8nh3xkj5rcx7ufkatvx6ueqhp5vfw9v5teq26z254renshtf3g0 [882785](https://mempool.marc26z.com/block/00000000000000000001840e7986ea4b6ea103f5af9b524dc102be926a831dee) [merch](https://marc26z.com/merch/) **Follow me on nostr**. All of my work is available under the Creative Commons 0 licence. If you would like to try my instance of Searxng and do not wish to support my work, find me on habla.news by searching my npub. You can find all of my work there(including encryption keys)free of charge. # Paywall On Substack abdominal.savior.repaint Will decrypt this ciphertext: 523FeCpi9Gx4nR9NmSFIMEaYcI5Q4WmhYHPEPaEah84= Which will reveal my instance of SearXNG at https://searxng.marc26z.com/ [Subscribe on Subtack](https://substack.com/@marc26z)

@ da0b9bc3:4e30a4a9

It's Finally here Stackers! It's Friday! We're about to kick off our weekends with some feel good tracks. Let's get the party started. Bring me those Feel Good tracks. Talk Music. Share Tracks. Zap Sats. Let's go! https://youtu.be/6Whgn_iE5uc?si=ArBOHVpKN2OyNf1D originally posted at https://stacker.news/items/879159

@ dbb19ae0:c3f22d5a

1. Downloading the linux package (1.8GB) https://cortex.so/docs/installation 2. Installing Cortex on linux is done via dpkg `sudo dpkg -i cortex-1.0.9-linux-amd64-local-installer.deb` it requires 2 linux packages (will add their names later) 3. When running Cortex, `cortex start` a local implementation will be running on http://127.0.0.1:39281 4. Using python it is possible to run queries make sure the model name is correct you can double check the value using: ` cortex ps` Now the python program to run one little query: ``` python import requests url = "http://127.0.0.1:39281/v1/chat/completions" headers = {"Content-Type": "application/json"} payload = { "model": "tinyllama:1b-gguf", "messages": [ { "role": "user", "content": "Write a joke" } ], "stream": False, "max_tokens": 128, "stop": ["End"], "frequency_penalty": 0.2, "presence_penalty": 0.6, "temperature": 0.8, "top_p": 0.95, } response = requests.post(url, json=payload, headers=headers) print(response.json()) ```

@ 2685c45c:8bc01bfd

## 1. Abstract A society is a group of individuals (members) who abide by common rules. A democracy is a society where members strive for rules defined with the maximum consciousness and consensus. To increase awareness, such a society must be completely transparent. The key challenge is to find the most consensual set of rules. Members could themselves decide: - Who to admit or exclude from membership - Which rules to submit for approval - How to approve proposed rules The proposed software does not: - Interpret the meaning of the rules - Prevent from having inconsistent sets of rules - Impose a governance structure Rather, it could be viewed as: - A framework for defining and running a society (a constitution) - A ledger which records all rules, votes and members in one place A client accessing the blockchain can, at any time, know: - The rights and duties of any member - The connections between members - The voting history of any member In summary, the software enables a web of trust on a blockchain used for voting. ## 2. A blockchain ### 2.1 Why using a blockchain The core of any society lies in maintaining an up-to-date registry of its members (1 member = 1 pubkey), along with their respective rights and duties. This information is recorded on a distributed blockchain. The advantages of using a distributed blockchain are: - No single central authority/server in charge of publishing society updates - Each block is a time unit to define anteriorities and thereby freeze the state of the society Unlike Bitcoin, there is no financial incentive to participate in the network. Instead, stakeholders may be motivated by their desire: - To support a society - To join a society - To remain part of a society ### 2.2 Structure of a block Members issue objects (as bitcoiners issue transactions) that are first stored in a mempool, prior to being 'blockchainized'. A Block has three parts: - Header - Hash of the signature of the preceding block - Object counter - Merkle root of the below objects - Content - All objects sorted - Footer - Signature of the block header (by the author of the block) Unlike Bitcoin: - There is no nonce - Objects must be arranged following an hard-coded sorting method - A block must have at least one object (no upper limit: no block size) - A block must be signed by its author - The hash of the signature constitutes the 'chain' connecting the 'blocks' > *@readers* > > We call 'block hash' the hash of the block's signature. > > In this paper, for clarity, the ideas of object's issuer and author are one. ### 2.3 Consensus mechanism Like in Bitcoin, the branch with the most leading zeros in its block hashes is the legitimate branch. To prevent spam, a block (at height n) will be relayed only if its hash is less than the one currently stored at height n. Block authors may choose to omit certain (available in mempool) objects from a block, as they would increase the block hash value. However, statistically, these excluded objects will contribute to lower a future block hash. Block time is agreed upon by members. Block authors should stick to this pace. Those who don't may be causing inconvenience for others, but won't compromise the consensus. Repeat offenders can be easily identified through their block signatures and could get banned. ### 2.4 Consensus attack An attack on the consensus can: - Censor a controversial object - Disrupt the chronology of the blockchainized objects A block author, attempting to manipulate the blockchain, can compute a malicious object solely designed to reduce his block hash. This tactic ensures that the maliciously created block will be accepted as part of the legitimate branch. This attack could be repeated on all future blocks. Some other attacks on the consensus are possible. A trustless blockchain requires POW. **But, the proposed blockchain is not trustless as it records a web of trust**. When needed, members will vote for the block they consider legitimate and it will contravene the default consensus rule. Actually, the real risk lies in members not trusting each other. ## 3. Objects ### 3.1 Common format Objects are JSONs. There are: - 5 different objects that can be recorded in the blockchain - 1 pseudo object that constitutes the blockchain The JSONs have standardized keys, known as 'attributes'. One of these is called 'core', which contains a further dictionary with its own standardized keys, known as 'fields'. > *@readers* > > - 'Pop' is abbreviated from 'population' > - 'Admin' is abbreviated from 'administration' ### 3.2 Link A link is created by 2 members signing their pubkeys. The web of trust comprises all these links. It serves as a civil registry. ### 3.3 Admin An admin: - Grants some members permission to issue some objects (even other admins) - Defines criteria for the issued objects approval (votes requirements) The set of approved admins defines the constitution of the society. Any core of an admin must have these fields: - Member: Pop of members allowed to issue objects - Boundary: Limitations on the issued objects - Approval: Vote requirements for the issued objects approval ### 3.4 Law A law is a human interpretable free text which applies to a defined pop of members. Any core of a law must have these fields: - Member: Pop of members on whom the law applies - Content: The content of the law ### 3.5 Vote A vote may concern any object (even another vote). Any core of a vote must have these fields: - Object: Pop of objects being voted - Side: The 'yes' or 'no' vote itself If a member votes twice on the same object, only the first one will count. To counteract this, the member would need to void his first vote. ### 3.6 Void A void is used to temporarily or permanently ignore objects (even other voids). Any core of a void must have these fields: - Object: Pop of objects to be ignored - Duration: Time period expressed in blocks, can be infinite Modifying an already blockchainized object requires to: 1. Void the object 2. Issue a newly created object with the wished modifications Once an admin is voided: - The children objects are unaffected - The voided admin cannot issue any further object The genesis admin, JSON object automatically created at system setup, grants full permissions to founding members. It allows them to create the first admins. Once this has been done, the genesis admin should be permanently voided. A member exists only by his links. Voiding all these means banning this member. > *@readers:* > > - 'Member pop' means 'pop of members' > - 'Object pop' means 'pop of objects' ### 3.7 Block A block is a pseudo object as it is not recorded in the blockchain but constitutes it. Like other objects: - An admin can grant some members permission to issue blocks - Issuing votes or voids concerning blocks can be allowed But unlike other objects: - Blocks do not possess explicit attributes like other JSON objects - The program implicitly assigns a 'type' attribute to blocks - Approved and voided blocks impact the default consensus rule Actually, the program identifies the legitimate branch according to the consensus rule (maximum cumulative heading 0), with these constraints: - All approved blocks must be part of this branch - This branch must not pass through any voided block In case of fork attack: - Block voters can vote for the right forking block - Block voiders could reconsider this decision voiding the approved forking block (trust crisis) > *@devs:* > > Approving/voiding blocks can lead to a rollback. Only genesis block is not approvable/voidable. ## 4. Attributes ### 4.1 Path Each object originates from the core of an admin which originates from the core of a parent admin. This continues until the genesis admin is reached. All objects and cores have an id. The path of an object A consists of all these ids: from the genesis admin till the id of A. Two blockchainized objects can't have the same path. In order to reduce conflicts, it can be advisable to choose large random numbers as ids. ### 4.2 Type An object can have only one type. A block always has the default type 'block'. A JSON object can't have this type. ### 4.3 Author This attribute stores the list of pubkeys of the members who wrote the object. Except for links, which must have exactly two authors, other objects can have from 1 to n authors. ### 4.4 Label This attribute allows members to tag objects. Members shall agree on standardized tags: tax, justice... They could even tag objects as belonging to an ideology or party. It would ease the work for voters who need guidance. ### 4.5 Context In addition to storing and relaying objects, servers can optionally store aside free texts and relay them as well. They provide explanations (such as contextual information) about the issued objects. This attribute enables linking a free text (through its hash) to an object. ### 4.6 Core All objects possess between 1 and n cores - though links which do not have one. They define the political essence of the objects. Practically, a core is a dictionary where allowed fields (keys) depend on the object type. ### 4.7 Signature Before object issuance, each member whose the pubkey is in the author list must sign all previously described attributes. This attribute stores the list of these signatures. ### 4.8 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 1 | path | list of ids | yes | yes | | 1 | type | 'link' or 'admin' or 'law' or 'vote' or 'void' | yes | yes | | 1 | author | list of pubkeys | yes | yes | | 1 | label | string of plain word(s) | yes | no | | 1 | context | string of an hash | yes | no | | 1 | core-n | dict of fields | no | yes, except for links | | 1 | signature | list of signatures | yes | yes | > *@devs:* > > In this paper, a list refers to a string where items are separated by commas without any blank space. > > Such lists are well suited for regex parsing. ### 4.9 Example The object below describes an admin with the id 29 originating from: - The core 3 of the admin 7 which originates from - The core 0 of the admin 0 (the genesis admin) This admin: - Is created by two members - Is tagged with the words 'trade' and 'justice' - Has a context file associated - Has two signatures ``` { 'path': '0-0,7-3,29', 'type': 'admin', 'author': '15a3b72c,b52d6e1a', 'label': 'trade justice', 'context': '5bc953e0', 'core-0': <This core allows to issue laws>, 'core-1': <This core allows to issue votes concerning the core-0 laws>, 'signature': '827d65b7,3c65da6b' } ``` ## 5. Member field ### 5.1 Applications The field member defines a member pop. It is used in: - Admin cores: Define who can issue objects - Law cores: Define who is concerned by the law ### 5.2 Composing pops Member pops can be composed using algebra of sets. Two keys are used: - Operand: A member pop - Operator: An operator (arity = 2) An operand is a dictionary that: - Defines a basic pop - Applies methods to this basic pop to adjust it Operators are either: - '+': Union: Merge two member pops - '-': Complement: Subtract from the first pop the members in the second pop - '&': Intersection: Keep only the members who are in both pops The simplest composition consists of just one operand. However, as shown in the following example, complex compositions (with priority rules) are also possible: - The operand-0 pop is the intersection of two other pops - The final pop is the operand-0 pop minus the operand-1 pop ``` 'core-0': |--'member': |--'operand-0': | |--'operand-10': ... | |--'operator-10': '&' | |--'operand-11': ... |--'operator-0': '-' |--'operand-1': ... ``` ### 5.3 Defining a basic pop These keys define a basic pop: - Base: Set a starting point to define the pop - Value: Define an argument to complete the base key - Future: Define whether the pop will evolve after object blockchainization The base key has these possible values: - Allmembers: - Includes all non banned members of the society - Useful for widespread rights/duties (i.e., the right to issue links) - Omits the value key - Nomember: - Doesn't include any member - Useful for giving rights/duties to few members or to members with specific locations in the graph - Supposed to be used with the method 'name' to add members to the pop - Omits the value key - Issuing: - Includes all members who have issued or co-issued objects belonging to a defined object pop - Useful for giving rights/duties to members according to their past actions - The value key must store an object pop - Pointing: - Points to an existing member pop - Useful for readability - The value key must store the path to an admin or law core The future key has these possible values: - Dynamic: The pop is recomputed at each new block by the program - Static: The pop is computed at the time of object blockchainization, only future voided links can still impact it ### 5.4 Adjusting a basic pop #### 5.4.1 Common format These keys define a method: - Method: The method's name - Arg: The argument passed to the method As several methods can be applied to the same basic pop, these keys are suffixed. These suffixes specify the methods order execution. #### 5.4.2 Name method It adds or removes the specified members from the basic pop. The arg must be a list of pubkeys prefixed by: - '+': Add member - '-': Remove member The program ignores added members who have been banned. Two keywords can be used instead of a pubkey: - @self: It denotes the pubkey(s) of the author(s) of the object - @center: It denotes the pubkey(s) of the member(s) located at the whole graph center > *@thinkers:* > > Does the center of the web of trust best reflect the values of the society? #### 5.4.3 Radius method It adds or removes members from the basic pop (which is a graph) based on how far they are from its center. The arg must be a positive or negative integer: - n: Radius + n links - -n: Radius - n links If given basic pop is a disconnected graph, the method is applied to each subgraph. > *@devs:* > > The distance between 2 members is the minimum number of links to join these 2 members. > > The center of a graph is composed of the members who have the smallest distance to all other members. > > The radius of a graph is this smallest distance. #### 5.4.4 Degree method It adds or removes members from the basic pop according to their number of links within it. This method can be used to exclude members not well integrated within the basic pop. The arg must be an integer which serves as a comparison: - n: n or more links - -n: n or less links > *@readers:* > > An integer which serves as a comparison is called a 'comparator'. ### 5.5 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | member | dict with below level-3 keys | yes | yes | | 3 | operand-n | dict with below level-4 keys | no | yes | | 4 | base | 'allmembers' or 'nomember' or 'issuing' or 'pointing' | yes | yes | | 4 | value | base='issuing', object pop <br> base='pointing', path to a core | yes | base='issuing'/'pointing', yes <br> base='allmembers'/'nomembers', no | | 4 | future | 'dynamic' or 'static' | yes | yes | | 4 | method-n | 'name' or 'radius' or 'degree' | no | no | | 4 | arg-n | method='name', list of +/- prefixed pubkeys <br> method='radius', integer (-inf,+inf) <br> method='degree', comparator (-inf,+inf)| no | any method requires an arg | | 3 | operator-n | '+' or '-' or '&' | no | no | ### 5.6 Examples The following example shows the union of two pops, forming the final member pop. The first pop is dynamic: it is re-computed at each new block. It includes: - All members within 20 hops radius around the graph's center - With at least 3 links within this 'extended central' pop The second pop references an existing member pop: the core-1 pop of the law or admin 2, itself originating from the core 0....until the genesis admin. The referenced pop could be dynamic. However, this second pop is static. ``` 'core-0': |--'member': | |--'operand-0': | | |--'core': 'nomember' | | |--'future': 'dynamic' | | |--'method-0': 'name' | | |--'arg-0': '+@center' | | |--'method-1': 'radius' | | |--'arg-1': 20 | | |--'method-2': 'degree' | | |--'arg-2': 3 | |--'operator': '+' | |--'operand-1': | | |--'core': 'pointing' | | |--'future': 'static' | | |--'value': '0-0,5-2,3-0,2-1' ``` The following example shows a pop comprising a single operand. It includes: - The object's author(s) - All his (their) current neighbors up to 5 hops away ``` 'core-0': |--'member': | |--'operand-0': | | |--'core': 'nomember' | | |--'future': 'dynamic' | | |--'method-0': 'name' | | |--'arg-0': '+@self' | | |--'method-1': 'radius' | | |--'arg-1': 5 ``` ## 6. Approval field ### 6.1 Application The approval field is used in the admin cores. It specifies voting requirements for issued objects approval. Approved objects have varying implications depending on their types: - Link: Only approved links comprise the graph (the web of trust) - Admin: Only approved admins can issue objects - Law: Once approved, a law applies to concerned members - Vote: Only approved votes counts to meet voting requirements - Void: Once approved, objects concerned by the void are ignored (voided) - Block: The legitimate branch must pass through the approved blocks > *@devs:* > > Except for laws, approved objects affect program behavior. ### 6.2 Defining approval requirements These keys define an approval field: - Quorum: Minimum percentage of voters required among eligible voters - Strength: Minimum percentage of 'yes' votes required among all votes The values of these keys are comparators between 0 and 100. If both values are equal to zero, it means that once blockchainized, the object is approved. The pop of eligible voters can be spread across multiple admin cores. It can also be dynamic, maintaining a perpetual approval uncertainty. > *@thinkers:* > > Should new eligible voters have the automatic right to challenge existing approved rules ? ### 6.3 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | approval | dict with below level-3 keys | yes | yes | | 3 | quorum | comparator [0,100] | yes | yes | | 3 | strength | comparator [0,100] | yes | yes | ### 6.4 Example In the following example, the approval requirements are: - At least 50% of the eligible voters must vote - At least 70% of the votes must be 'yes' votes ``` 'core-0': |--'approval': | |--'quorum': 50 | |--'strength': 70 ``` ## 7. Content field The content field is used in the law cores. It's a text open to human interpretation defining the content of a law. | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | content | free text | yes | yes | ## 8. Object field ### 8.1 Applications The object field defines an object pop. It is used for these objects: - Vote: Define the objects voted - Void: Define the objects to ignore Object pops can be composed in the same way as member pops (same operators). ### 8.2 Defining an object pop An object pop is a dictionary where key names mirror some attribute and field names. These keys act as filters (criteria) to select relevant objects. An object pop includes all objects that: - Satisfy criteria at attribute level - Have **at least one core** that satisfies all criteria at field level Meeting a criterion depends on its type: - Regex: Full match with mirrored attribute or field - Pop: Include mirrored pop Depending on the criteria, object pops can be static or dynamic. However, issuing votes or voids concerning a dynamic object pop means voting or voiding non yet issued objects! UX should prevent this risk. ### 8.3 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | object | dict with below level-3 keys | yes | yes | | 3 | operand-n | dict with below level-4 keys | no | yes | | 4 | path | regex | yes | no | | 4 | type | regex | yes | no | | 4 | author | member pop | yes | no | | 4 | label | regex | yes | no | | 4 | member | member pop | yes | no | | 4 | object | object pop | yes | no | | 4 | side | regex | yes | no | | 3 | operator-n | '+' or '-' or '&' | no | no | ### 8.4 Examples The following example shows an object pop, including objects: - Originating from the core 2 of the admin 9 (itself originating from the genesis admin) - With ids from 0 to 5 - That are voids or laws - That have the word 'CUSTO' in their labels ``` 'core-0': |--'object': | |--'path': '0-0,9-2,[0-5]' | |--'type': 'void|law' | |--'label': '.*CUSTO.*' ``` The following example shows an object pop which includes any object originating from the core 2 of the admin 9. It includes eventual admins and their children objects. This kind of dynamic object pops should be used carefully. ``` 'core-0': |--'object': | |--'path': '0-0,9-2,.*' ``` The following example could be an extract of a vote which concerns voids: - Originating from the core 5 of the admin 8 - Issued (or co-issued) by any member currently located within a 3-hop radius around the member 4f52da24 - Concerning laws originating from the cores 0 to 4 of the admin 8 ``` 'core-0': |--'object': | |--'operand': | | |--'path': '0-0,8-5,[0-9]*' | | |--'type': 'void' | | |--'author': | | | |--'operand': | | | | |--'base': 'nomember' | | | | |--'behavior': 'dynamic' | | | | |--'method-0': 'name' | | | | |--'arg-0': '+4f52da24' | | | | |--'method-1': 'radius' | | | | |--'arg-1': 3 | | |--'object': | | | |--'operand': | | | | |--'path': '0-0,8-[0-4]' | | | | |--'type': 'law' ``` > *@thinkers:* > > A vote concerning voids which concern laws. > > Getting the hang of it requires some mental effort! ## 9. Side field The side field is used in the vote cores. It tells whether it's a yes or no vote. | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | side | 'yes' or 'no' | yes | yes | ## 10. Duration field ### 10.1 Application The duration field is used in void cores. It specifies how long the program ignores the voided object. ### 10.2 Defining duration The duration field can have these values: - 0: Voided objects are forever ignored - n (with n>0): Voided objects are ignored during n blocks The timeframe starts after void approval. ### 10.3 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | duration | integer [0,+inf) | yes | yes | ## 11. Boundary field ### 11.1 Application The boundary field is used in admin cores. It limits the objects that can be issued. These keys define a boundary field: - Content: To restrict the content of the issued objects - Amount: To limit the amount of objects issued An object that does not fully respect the boundary field will be rejected by the network. ### 11.2 Restricting content The content key stores a dictionary where key names mirror some attribute and field names. These keys act as criteria to filter the objects that can be issued. These objects must: - Satisfy criteria at attribute level - Have **all their cores** satisfying criteria at field level Blocks possess only the type attribute. Therefore, a content restriction on blocks can only allow or forbid issuance. Meeting a criterion depends on its type: - Regex: Full match with mirrored attribute or field - Pop: Include mirrored pop - Comparator: Respect comparison logic - Boundary: - This criterion type is used to limit the boundary field of a meta-admin - A meta-admin is an admin that can generate child admins - It consists of the same data as a boundary field - All the restrictions of the mirrored boundary field must be more stringent > *@devs:* > > A regex can be more stringent than another one. For example, '[0-9]{2}' is more stringent than '[0-9]+'. Boundary criterion requires to code such a regex assessor. ### 11.3 Restricting amount These keys define the amount restriction: - Scope: - Meaning: The below restrictions can be either per member or for the whole member pop - Value: Either the string 'each' or the string 'all' - Maximum: - Meaning: Maximum number of issued objects (excluding issued objects voided) - Value: A negative non null comparator - Frequency: - Meaning: Required time gap (expressed in blocks) between object issuance - Value: A positive or null comparator ### 11.4 Digest | level | key | value | uniqueness | mandatory | | - | - | - | - | - | | 2 | boundary | dict with below level-3 keys | yes | yes | | 3 | content | dict with below level-4 keys | yes | no | | 4 | path | regex | yes | no | | 4 | type | regex | yes | no | | 4 | author | member pop | yes | no | | 4 | label | regex | yes | no | | 4 | member | member pop | yes | no | | 4 | approval | dict with below level-4 keys | yes | no | | 5 | quorum | comparator [0,100] | yes | no | | 5 | strength | comparator [0,100] | yes | no | | 4 | object | object pop | yes | no | | 4 | duration | comparator (-inf,+inf) | yes | no | | 4 | boundary | boundary | yes | no | | 3 | amount | dict with below level-3 keys | no | no | | 4 | scope | 'all' or 'each' | yes | no | | 4 | maximum | comparator (-inf,-1] | yes | no | | 4 | frequency | comparator [0,+inf) | yes | no | > *@devs:* > > The comparator for duration has a quirk. Indeed, a zero duration means forever. ### 11.5 Examples The boundary field in the following example allows to issue laws: - That include the word 'medicine' in their labels - That concern all current and future members (or any sub-pop of this pop) ``` 'core-0': |--'boundary': | |--'content': | | |--'type': 'law' | | |--'label': '.*medicine.*' | | |--'member': | | | |--'operand-0': | | | | |--'base': 'allmembers' | | | | |--'future': 'dynamic' ``` The admin core described in the following example: - Allows all current and future members - To issue links - That are automatically approved The amount of issued links is limited: - Up to 8 links maximum per member (excluding issued links voided) - Each member must wait 1,095 blocks between two links ``` 'core-0': |--'member': | |--'operand-0': | | |--'base': 'allmembers' | | |--'future': 'dynamic' |--'boundary': | |--'content': | | |--'type': 'link' | |--'amount': | | |--'scope': 'each' | | |--'maximum': 8 | | |--'frequency': 1095 |--'approval': | |--'quorum': 0 | |--'strength': 0 ``` The admin core described in the following example: - Allows all current and future members - To issue voids - That are automatically approved These voids must: - Have the exact value 'unlink' as label - Concern links written by the void author and his direct neighbors This admin core allows each member to void his own links. Motivations might be: - The loss of confidence in a direct neighbor - The death of a direct neighbor - The wish to opt-out from the society ``` 'core-0': |--'member': | |--'operand-0': | | |--'base': 'allmembers' | | |--'future': 'dynamic' |--'boundary': | |--'content': | | |--'type': 'void' | | |--'label': 'unlink' | | |--'object': | | | |--'operand-0': | | | | |--'type': 'link' | | | | |--'author': | | | | | |--'operand-0': | | | | | | |--'base': 'nomember' | | | | | | |--'future': 'dynamic' | | | | | | |--'method-0': 'name' | | | | | | |--'arg-0': '+@self' | | | | | | |--'method-1': 'radius' | | | | | | |--'arg-1': 1 |--'approval': | |--'quorum': 0 | |--'strength': 0 ``` The meta-admin core described in the following example: - Allows 3 members - To issue admins - That require votes to be approved (80-30) These admins: - Allow some members (center + 50 hops and 6 or more links) - To issue laws - That require votes to be approved (60-50) These laws: - Must include the word 'newcomer' in their labels - Must concern all members with 3 or less links ``` 'core-0': |--'member': | |--'operand-0': | | |--'base': 'nomember' | | |--'future': 'static' | | |--'method-0': 'name' | | |--'arg-0': '+d15a4c8f,+4867ae22,+a1f8c7d4' |--'boundary': | |--'content': | | |--'type': 'admin' | | |--'member': | | | |--'operand-0': | | | | |--'base': 'nomember' | | | | |--'future': 'dynamic' | | | | |--'method-0': 'name' | | | | |--'arg-0': '+@center' | | | | |--'method-1': 'radius' | | | | |--'args-1': 50 | | | | |--'method-2': 'degree' | | | | |--'arg-2': 6 | | |--'boundary': | | | |--'content': | | | | |--'type': 'law' | | | | |--'label': '.*newcomer.*' | | | | |--'member': | | | | | |--'operand-0': | | | | | | |--'base': 'allmembers' | | | | | | |--'future': 'dynamic' | | | | | | |--'method-0': 'degree' | | | | | | |--'arg-0': '-3' | | |--'approval': | | | |--'quorum': 60 | | | |--'strength': 50 |--'aproval': | |--'quorum': 80 | |--'strength': 30 ``` > *@thinkers:* > > We don't recommend creating short-lived admins. > > A sturdy constitution (set of admins), is the hallmark of good governance. ## 12. Staying united ### 12.1 Membership feeling Using a web-of-trust to register members has several effects on social dynamics, including boosting the sense of community. Moreover, the more governance reflects members preferences, the greater this effect becomes. ### 12.2 Banning a member To prevent banned members from reappearing with new identities (new pubkeys), doxing them is essential. A highly adversarial environment would demand such caution: 1. Any member can denunciate a suspect to 'initiators' 2. 'Initiators' decide whether to issue a void concerning the links of the suspect 3. 'Neighbors' of the suspect should reveal his identity to the 'initiators' 4. 'Initiators' issue a report on the suspect to the 'judges' 5. 'Judges' vote for or against the void 6. If the void is approved, the suspect is banned and the initiators issue a law to dox him Ideally: - Communications in steps 1, 3 and 4 should be encrypted for the intended recipients - Neighbors should cooperate with initiators to avoid raising suspicions! - The report sent to judges should be anonymized Organizing the ban process in real life can be much more simple but it entails risks. Social enginery can mitigate these risks. ### 12.3 Sybill attack An attacker could assume several identities. To tackle this problem, above banning process applies with these exceptions: - Several suspects are involved - Reports can't be anonymized ### 12.4 Adversarial environment This chapter explores a high-risk use case: breaking free from an oppressive and centralized state. In this context, decentralization and anonymity are essential to survive. A society is as strong and attractive as its members being supportive of each other. This involves fostering an exclusive commercial environment. Businesses need to be encouraged while keeping members' privacy concerns paramount. In an extreme scenario, producers should trade only with their direct neighbours, who endorse the role of trader with their own direct neighbours, thus mirroring the graph's topology. Encrypting blockchain content to restrict access to members only is a misguided approach. It creates an air of mystery around the society's intentions, fuelling fear instead. To counter this, it's crucial to showcase the society's benevolent intentions, thereby undermining central state oppression and making the system as appealing as possible. The state might anyway hinder the development of such a society. In response, members could adopt this defensive strategy: 1. Dox on chain low-level managers overseeing state violence and their supports 2. Halt solidarity with doxed people until they give up doing evil 3. Update the list of doxed people 4. Attract operators of the resigned managers to enforce justice in their own society > *@thinkers:* > > We believe **total** social exclusion produces better outcomes than physical violence. We **never** encourage the latter. ## 13. Conclusion We have proposed a system for a decentralized and pseudonymous society where a built-in script language provides unparalleled flexibility in designing the constitution. Only hands-on use can demonstrate its value. The potential impact on human organizations is considerable and we urge careful consideration. All lives matter. ## 14. ANNEX 1: UX ### 14.1 A UX per use case Any political venture vulnerable to central powers could fall back on the proposed software: - Collaborative encyclopaedia - Sport association or committee - ... Devs could share customized plugins for each use case. A plugin comprises: - A set of pre-built objects - A UX Incorporating a plugin into the software would make a big difference in terms of usability: - Wizard for society setup (constitution) - Template objects to reuse/customize - Template pops and regex to reuse/customize - Simplified interface for voting - ... A draft, generic, by default, UX is detailed below. ### 14.2 Main view ``` +--------------------------------------------------------------------------+ | url: https://www.node_accepting_connections_from_some_trusted_members.io | +-------------------------+------------------------------------------------+ | Member focused | | | -------------- | o---------o---------o-------o-----o------o | | | \ /|\ / \ / /| | | | [Enter here a pubkey] | \ / | \ / \ / / | | | | | \ / | o / \ / / | o | | | States considered | \ / | \ / / / | / | | | ----------------- | o----|----o / \ / | / | | | | | / \ / \ / |/ | | | [ ] Mempool | | / \ / o------o------o | | [x] Blockchainized | | / \ / | | | | [x] Approved | |/ o-------o------o | | [ ] Voided | o | | | | +-------------------------+------------------------------------------------+ | Understand | Behave | Act | |--------------------------------------------------------------------------| | | | These 3 tabs are explained further | | | +--------------------------------------------------------------------------+ ``` The main view is divided into three sections: - Focus: Set global settings - Graph: Display the web of trust - Explorer: Explore and create objects Focus section affects both Graph and Explorer sections that: - Adopt the selected member's point of view - Show only objects with the desired states The explorer section is divided into three tabs. ### 14.3 Understand tab ``` +-------------------------+------------------------------------------+------------------------------------+ | Tree | Children | Content | +-------------------------+------------------------------------------+------------------------------------+ | v id 0 | Select | id | type | label | Status | v attributes | | |-v core 0 |------------------------------------------| |-> path: 0-0,1-0,0-0,2 | | | |-v id 0 | ( ) | 0 | law | cadaster | approved | |-> type: law | | | | |-> core 0 | ( ) | 1 | law | cadaster | approved | |-> ... | | | | |-> core 1 | (x) | 2 | law | cadaster | approved | |-v core 0 | | | |-v id 1 | ( ) | 3 | void | cadaster | approved | | |-v member | | | | |-v core 0 |------------------------------------------| | | |-v operand 0 | | | | | |-v id 0 | | | | | |-> base: allmembers | | | | | | |-> >>core 0<< | | | | | |-> future: dynamic | | | | | | |-> core 1 | | | | |-v content | | | | +--------------------------------+ | | | | | Upon approval of this law, | | | | | | a45br7h6 will become the owner | | | | | | of property 8394144 | | | | | +--------------------------------+ | +-------------------------+------------------------------------------+------------------------------------+ ``` The Understand tab serves as an object explorer. It is divided into three panels: - Tree: Tree of all admins - Children: Children objects of the selected item in the Tree panel: - An admin: A list of the cores of this admin - A core: A list of the objects originating from this core - Content: Content of the selected item in the Children panel: - A core: The JSON content of this core - An object: The JSON content of this object - No selection: The JSON content of the selected admin or core in the Tree panel ### 14.4 Behave tab ``` +---------------------------------------------------------+-------------------------------------------+ | Regulation | Content | +---------------------------------------------------------+-------------------------------------------+ | Label filter: [Add text to filter objects i.e. 'tax'] | v attributes | |---------------------------------------------------------| |-> path: 0-0,2-0,6 | | Select | path | label | status | |-> type: law | |---------------------------------------------------------| |-> issuer: 2dac829k, b7ff56ff | | ( ) | 0-0,1-2,3-4,5 | tax water | approved | |-> label: tax property | | (x) | 0-0,2-0,6 | tax property | blockchainized | |-> context: s7w7y89f | | ( ) | 0-0,3-4,0-2,5 | foreigner tax | mempool | | | |-v operand 0 | |---------------------------------------------------------| | | | |-> base: allmembers | | | | | | |-> future: dynamic | | | | | |-v content | | | +---------------------------------------+ | | | | Monthly payment expected: | | | | | - Amount: 500¥ per square meter owned | | | | | - Address: 3dsh4r44 | | | | | Well indicate your pubkey in the tx | | | | +---------------------------------------+ | |---------------------------------------------------------+-------------------------------------------+ ``` The Behave tab enables access to all laws concerning the selected member. It is divided into three panels: - Regulation: All laws concerning the selected member - Content: JSON content of the selected law ### 14.5 Act tab ``` +-------------------------+-----------------------------------+---------------------------------------+ | Tree | Content | Writer | +-------------------------+-----------------------------------+---------------------------------------+ | v id 0 | v core | v attributes | | |-v core 0 | |-v member | |-> path: 0-0,1-0,0-0,[Add id] | | | |-v id 0 | | |-v operand 0 | |-> type: vote | | | | |-> core 0 | | | |-> base: nomember | |-> pubkey: 78cq32hu, [Add cosigner] | | | | |-> core 1 | | | |-> future: dynamic | |-> label: [Add label] | | | |-v id 5 | | | |-> method 0: name | |-> context: [Add hash] | | | | |-v core 2 | | | |-> arg 0: +@center | |-v core 0 | | | | | |-v id 3 | |-v boundary | | |-v object | | | | | | |-> core 6 | | |-v content | | | |-v operand 0 | | | | | | |-> >>core 7<< | | | |-> type: vote | | | | |-> path: [Add regex] | | | | | |-v object | | |-> side: [Add 'yes' or 'no'] | | | | | | |-v operand 0 | | | | | | | | |-> path: 0-0,5-2,3-6,.+ | +----------+ | | | |-v approval | | Add core | | | | | |-> quorum: 0 | +----------+ | | | | |-> strength: 0 | +-----------------------+ | | | | | Sign and issue object | | | | | +-----------------------+ | +-------------------------+-----------------------------------+---------------------------------------+ ``` The Act tab enables to write and issue objects. It is divided into three panels: - Tree: Tree of the admins where the selected member has issuance rights - Content: JSON content of the core selected - Creator: Form to write an object (require privkey; the selected member = the visitor)

@ b83a28b7:35919450

Avi Burra’s *24* is an ambitious and intricately woven narrative that blends mystery, philosophy, and technology into a modern odyssey. At its heart, the novel is a deeply personal story about grief, identity, and legacy, but it also serves as a meditation on the interplay between cryptography, art, and human connection. Burra’s debut novel is as much a puzzle as it is a journey of self-discovery, with its protagonist, Oliver Battolo, unraveling a twenty-four-word seed phrase left behind by his enigmatic father—a key to both a vast Bitcoin fortune and deeper truths about life. --- ### **The Plot: A Cryptographic Quest** The novel begins with Oliver grappling with the death of his father, Nate Battolo. At Nate’s funeral, Oliver discovers a cryptic message instructing him to find twenty-four words. These words form the seed phrase to a Bitcoin wallet. Guided by Maren, a spiritual healer and family friend, Oliver learns “time projection,” a meditative technique that allows him to access symbolic memories and alternate realities. Through these projections and real-world encounters, Oliver uncovers the twenty-four words while unraveling his father’s hidden life as an early contributor to Bitcoin. As the narrative progresses, Oliver uncovers shocking truths about his father’s role in the early days of Bitcoin. Alongside this technological intrigue are surrealist elements tied to Jonathan Bryce’s cryptographic paintings, which serve as both literal and metaphorical keys to unlocking Nate’s secrets. --- ### **Themes: A Philosophical Mosaic** Burra masterfully interweaves several themes throughout *24*, including: - **Grief and Legacy**: The novel explores how Oliver processes his father’s death while uncovering Nate’s hidden life. The journey forces him to reconcile his father’s flaws with his brilliance. - **Identity and Reinvention**: From Nate’s transformation into “Nate Battolo” at Princeton to Oliver’s own self-discovery, the novel examines how identities are shaped by choices and circumstances. - **Philosophy and Non-Duality**: The enigmatic Noncemeister—a surreal guide representing collective consciousness—teaches Oliver about interconnectedness and non-duality, echoing traditions like Advaita Vedanta and Zen Buddhism. - **Cryptography Meets Art**: Jonathan Bryce’s paintings symbolize hidden knowledge waiting to be deciphered, blending surrealist aesthetics with cryptographic principles. - **Moral Complexity**: The Bitcoin fortune represents both opportunity and burden, forcing Oliver to grapple with ethical dilemmas about wealth, surveillance, and personal responsibility. --- ### **Strengths** Burra excels at creating a layered narrative that balances intellectual depth with emotional resonance. The philosophical musings of the Noncemeister are thought-provoking without being didactic, offering readers insights into non-duality and existentialism. The integration of cryptography into the plot is seamless; even readers unfamiliar with Bitcoin will find themselves intrigued by its implications for freedom and control. Additionally, the novel’s surrealist elements—particularly the time projection episodes—are vividly described and lend the story an otherworldly quality. The relationship between Oliver and his father is particularly compelling. Through flashbacks and projections, Nate emerges as a complex figure—brilliant yet flawed—whose decisions ripple through Oliver’s life in unexpected ways. This emotional core grounds the novel amidst its more abstract explorations. --- ### **Weaknesses** While *24* is undeniably ambitious, its complexity may alienate some readers. The dense philosophical passages—though rewarding for those who enjoy intellectual challenges—can feel overwhelming at times. Similarly, the technical details about Bitcoin and cryptography might be difficult for readers unfamiliar with these topics. The ending leaves several threads unresolved, including the fate of two additional Bryce paintings hinted at in the epilogue. While this ambiguity adds to the novel’s mystique, it may frustrate readers seeking closure. --- ### **Conclusion** *24* is a bold debut that defies easy categorization. Part mystery, part philosophical treatise, part technological exploration—it is a novel that challenges its readers while rewarding their patience. Avi Burra has crafted a story that is as much about finding twenty-four words as it is about finding oneself. With its intricate plot, rich themes, and memorable characters, *24* establishes Burra as a writer to watch. For readers who enjoy intellectual puzzles wrapped in emotional depth—think Haruki Murakami meets Neal Stephenson—*24* is an unforgettable journey worth taking.

@ abab50be:430cd35d

Setup up my NIP-05... Hoping this works! originally posted at https://stacker.news/items/879027

@ 3b7fc823:e194354f

### Privacy in Public Spaces: A Tactical Guide #### 1. Public Wi-Fi Privacy Using public Wi-Fi can be convenient, but it's important to take precautions to protect your privacy: - **Use a VPN (Virtual Private Network)**: A VPN encrypts your internet traffic, making it difficult for hackers to intercept your data. - **Disable Automatic Connections**: Prevent your device from automatically connecting to open Wi-Fi networks by turning off this feature in your settings. - **Avoid Sensitive Transactions**: Refrain from accessing banking or other sensitive accounts while connected to public Wi-Fi. - **Use Secure Websites**: Look for "https://" in the website's URL to ensure it uses encryption. - **Keep Software Updated**: Ensure your device's operating system and apps are up-to-date to protect against security vulnerabilities. #### 2. Surveillance Camera Awareness Surveillance cameras are common in public spaces. Here are some strategies to maintain your privacy: - **Spotting Cameras**: - **Look for Signs**: Many establishments post signs indicating the presence of surveillance cameras. - **Camera Placement**: Cameras are often placed near entrances, exits, and high-traffic areas. Look for dome-shaped cameras on ceilings or wall-mounted cameras. - **Using Masks and Coverings**: - **Face Masks**: Wearing a mask can help obscure your facial features from facial recognition systems. - **Hats and Sunglasses**: A hat can shield your face from overhead cameras, while sunglasses can hide your eyes. - **Covering Identifying Marks**: - **Clothing Choices**: Wear clothing that doesn't have distinctive logos or patterns that can easily identify you. - **Blend In**: Opt for styles and clothing choices that helps you blend in with your surroundings, reducing your visibility. - **Temporary Coverings**: Consider using temporary coverings, such as scarves or hoods, to conceal tattoos or other identifying marks. #### 3. General Privacy Tips in Public Spaces - **Be Mindful of Your Surroundings**: Pay attention to your environment and be aware of any unusual behavior or devices that may be capturing your information. - **Limit Personal Information**: Avoid discussing sensitive information in public where it can be overheard. - **Use Encrypted Messaging Apps**: Apps like Signal or SimpleX offer end-to-end encryption for your messages, making it harder for eavesdroppers to intercept your conversations. - **Use Privacy Screens**: Privacy screens on all of you electronic screens can defend against the over the shoulder peek or side eye. - **Avoiding Behaviors**: Be mindful of behaviors that could make you a target, such as frequent visits to certain areas or engaging in conversations that might attract unwanted attention. Taking these steps can help you maintain your privacy while navigating public spaces and using public Wi-Fi. Remember, staying informed and vigilant is key to protecting your personal information. --- Advocating for privacy does not finance itself. If you enjoyed this article, please consider zapping or sending monero 82XCDNK1Js8TethhpGLFPbVyKe25DxMUePad1rUn9z7V6QdCzxHEE7varvVh1VUidUhHVSA4atNU2BTpSNJLC1BqSvDajw1

@ 1cb14ab3:95d52462

***Tree branches, driftwood coconut. 5'7" teardrop. [Dawei, Myanmar. 2020]*** --- #### Introduction Situated on Myanmar’s Grandfather Beach, this lens captures the dramatic shape of a steep, rocky hill that mirrors the arduous road leading to this remote location. Grandfather invites viewers to reflect on the connection between journey and destination, highlighting the tension and beauty of paths less traveled. #### Site & Placement The lens is positioned at the west end of the beach, focusing on the sharp hill rising above the shoreline. Its teardrop shape accentuates the rocky prominence, emphasizing its similarity to the road that winds toward the beach. A bench, placed 12 feet away, provides a place for viewers to absorb the rugged beauty of the scene. #### Impermanence & Integration Crafted from driftwood, branches, and stone, Grandfather is a fleeting presence in this timeless landscape. Its brief existence reflects the challenges and ephemerality of the journey it highlights, blending into the environment as it gradually succumbs to the elements. #### Reflection *Grandfather* invites viewers to consider the parallels between the physical journey to reach the beach and life’s broader paths. It stands as a reminder that even the most challenging routes can lead to moments of profound beauty. --- ## Photos         --- #### More from the 'Earth Lens' Series: [Earth Lens Series: Artist Statement + List of Works](https://hes.npub.pro/post/1731091744332/) ["Looking Glass" (Earth Lens 001)](https://hes.npub.pro/post/1736304563962/) ["Folsom" (Earth Lens 002)](https://hes.npub.pro/post/1737844073125/) ["Sanctuary" (Earth Lens 003)](https://hes.npub.pro/post/1731091744332/) ["Platte" (Earth Lens 004)](https://hes.npub.pro/post/sya8nv6q8k0w3olqcepwz) [COMING SOON: "Chongming" (Earth Lens 006)](https://hes.npub.pro/post/1731091744332/) --- #### More from Hes [Portfolio](https://hesart.npub.pro) [Online Store](https://plebeian.market/community/hes@nostrplebs.com/hesmart-ym3fcufdfz) [Artist Statements](https://hes.npub.pro/tag/art/) [Travel Guides](https://hes.npub.pro/tag/travel/) [Photography](https://hes.npub.pro/tag/photography) [Money](https://hes.npub.pro/tag/money) [Tech](https://hes.npub.pro/tag/tech) --- *All images are credit of Hes, but you are free to download and use for any purpose. If you find joy from my art, please feel free to send a zap. Enjoy life on a Bitcoin standard.*

@ f683e870:557f5ef2

After many months of ideation, research, and heads-down building, <span data-type="mention" data-id="726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11" data-label="nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9">@nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9</span> and myself are excited to announce our new project called Vertex. **Vertex’s mission is to provide developers and builders with the most up-to-date and easy-to-use social graph tools**. Our services will enable our future customers to improve the experience they provide by offering: - Protection against **impersonation** and **DoS attacks** - Personalized **discovery** and **recommendations**. All in an open, transparent and interoperable way. ## Open and Interoperable We have structured our services as [NIP-90 Data Vending Machines](https://github.com/nostr-protocol/nips/blob/master/90.md). We are currently using [these DVMs](https://vertexlab.io/docs/nips) and we are eager to hear what the community thinks and if anyone has suggestions for improvements. Regardless of their specific structures, using DVMs means one very important thing: **no vendor lock-in**. Anyone can start processing the same requests and compete with us to offer the most accurate results at the best price. This is very important for us because we are well aware that services like ours can potentially become a central point of failure. The ease with which we can be replaced by a competitor will keep us on our toes and will continue to motivate us to build better and better experiences for our customers, all while operating in an ethical and open manner. Speaking of openness, we have released **all of our code under the [MIT license](https://spdx.org/licenses/MIT.html)**, which means that anyone can review our algorithms, and any company or power user can run their own copies of Vertex if they so wish. We are confident in this decision because the value of Vertex is not in the software. It is in the team who designed and implemented it – and now continually improves, manages and runs it to provide the most accurate results with the lowest latency and highest uptime. # What we offer We currently support three DVMs, but we plan to increase our offering substantially this year. 1. `VerifyReputation`: give your users useful and personalized information to asses the reputation of an npub, minimizing the risk of impersonations. 2. `RecommendFollows`: give your users personalized recommendations about interesting npubs they might want who to follow. 3. `SortAuthors`: give your users the ability to sort replies, comments, zaps, search results or just about anything using authors’ reputations. To learn more, watch this 3-minute walk-through video, and [visit our website](https://vertexlab.io/) https://cdn.satellite.earth/6efabff7da55ce848074351b2d640ca3bde4515060d9aba002461a4a4ddad8d8.mp4 We are also considering offering a custom service to help builders clarify and implement their vision for Web of Trust in their own applications or projects. Please reach out if you are interested.

@ 5d4b6c8d:8a1c1ee3

Ate a little later yesterday. I took my daughter for a scooter ride on a trail near our house (I was walking) and she wanted to go farther than normal. Great for the steps challenge. Then, as soon as we turned around to go home, she decided she was too tired to scoot anymore. So, I got to do the return leg of the walk carrying both the kid and her scooter. We were out about an hour longer than expected, hence the later meal. ## Score Card Day 1: 14 hour fast (13 dry) Day 2: 15 hour fast (14 dry) Day 3: 17 hours (16 dry) Day 4: 18 hours (17 dry) Day 5: 18 hours (16 dry) Day 6: 19 hours (16 dry) Day 7: TBD (15 dry) originally posted at https://stacker.news/items/878700