@ 0c503f08:4aed05c7

My host is Debian and I'm using VirtualBox. Everything seems to be working well. originally posted at https://stacker.news/items/906016

@ d6c48950:54d57756

I wanted to write my system for bitcoin inheritance and seed storage that will likely outlive me - the reason why is recently bitkey (squares hardware wallet) announced their inheritance system which is a vast improvement but still has a single point of failure square and the app they maintain though this is still a good thing and will improve the ecosystem and raise awareness there is a cheaper method that is just a secure but doesn’t have a single point of failure. ## 2/3 seed storage 2/3 seed storage is actually a pretty simple way of splitting up a key into three parts, if you have one part it’s useless, if you have any two parts it’s complete - if one piece is destroyed it doesn’t matter (demo below) | A<br/> | B<br/> | C<br/> | |-----|-----|-----| | 1. apple<br/> | 2. zipper<br/> | 3. dog<br/> | | 4. tree<br/> | 5. car<br/> | 6. bus<br/> | | 7. banana<br/> | 8. motorbike<br/> | 9. dune<br/> | | 10. frank<br/> | 11. foundation<br/> | 12. meditation<br/> | | 13. whiteboard<br/> | 14. laptop<br/> | 15. books<br/> | | 16. perfume<br/> | 17. computer<br/> | 18. stone<br/> | | 19. brick<br/> | 20. spreadsheet<br/> | 21. bird<br/> | | 22. blog<br/> | 23. leaves<br/> | 24. grass<br/> | This is a seed phrase split up into three parts (a,b,c) - now you can create your 3 parts (1) | A<br/> | B<br/> | | |-----|-----|-----| | 1. apple<br/> | 2. zipper<br/> | | | 4. tree<br/> | 5. car<br/> | | | 7. banana<br/> | 8. motorbike<br/> | | | 10. frank<br/> | 11. foundation<br/> | | | 13. whiteboard<br/> | 14. laptop<br/> | | | 16. perfume<br/> | 17. computer<br/> | | | 19. brick<br/> | 20. spreadsheet<br/> | | | 22. blog<br/> | 23. leaves<br/> | | (2) | | B<br/> | C<br/> | |-----|-----|-----| | | 2. zipper<br/> | 3. dog<br/> | | | 5. car<br/> | 6. bus<br/> | | | 8. motorbike<br/> | 9. dune<br/> | | | 11. foundation<br/> | 12. meditation<br/> | | | 14. laptop<br/> | 15. books<br/> | | | 17. computer<br/> | 18. stone<br/> | | | 20. spreadsheet<br/> | 21. bird<br/> | | | 23. leaves<br/> | 24. grass<br/> | (3) | A<br/> | | C<br/> | |-----|-----|-----| | 1. apple<br/> | | 3. dog<br/> | | 4. tree<br/> | | 6. bus<br/> | | 7. banana<br/> | | 9. dune<br/> | | 10. frank<br/> | | 12. meditation<br/> | | 13. whiteboard<br/> | | 15. books<br/> | | 16. perfume<br/> | | 18. stone<br/> | | 19. brick<br/> | | 21. bird<br/> | | 22. blog<br/> | | 24. grass<br/> | Now you have your parts, you need at least 2/3 for it to be useful. ## distribution Distribution is pretty simple, keep one part, give a part to whomever you want to be able to claim your bitcoin upon death, give a part to someone you trust (along with instructions to post it to the claimant upon your death). ## failure For this to fail either 1. Two out of three parts would have to be destroyed 2. The trusted party would have to not post it AND either your part or the claimants would have to be destroyed 3. The trusted party cannot figure out how to use a seed phrase (by default you should include instructions i.e NEVER SHARE THE SEED, transfer to a recommended wallet from bitcoin.org then transfer to an exchange and sell)

@ 43baaf0c:d193e34c

Bangkok art city.  Bangkok is a highly creative city, which is one of the reasons I love living here. I’d love to hold a second exhibition something special and even bigger than before. The fact that all major galleries are free to the public says a lot about how much Bangkok values art. <iframe width="560" height="315" src="https://www.youtube.com/embed/6ddpEoSn_os?si=YKg6JRcsta1oNY9b" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> Over the last five months, I’ve been developing BangPOP art as both a concept and a blueprint for exhibitions worldwide. It serves as a guideline to ensure recognizable elements in each exhibition or event. While the artwork itself will always be unique, the POP Up exhibitions will have a distinct and recognizable identity wherever they take place.  You can read here the https://bitpopart.com/bangpop POP exhibition blue print.  Unfortunately, my plan to hold an exhibition at River City in Bangkok doesn’t seem to be coming together. Here’s the curator’s note: ‘our exhibition schedule on the 2nd floor this year and next year are quite packed and we have received numerous proposals at this moment.‘  After considering alternative venues in Bangkok, I’m optimistic about finding the right fit. For now, my focus is shifting to Europe, where I’ll use the BangPOP blueprint as my guiding framework.   Thank you Bangkok! 

@ f3873798:24b3f2f3

Olá pessoal! Estas altas temperaturas mais períodos de chuvas, é um prato cheio para a proliferação de mosquitos o que além de ser um incomodo pode ser tornar questão de saúde pública devido as doenças trazidas por eles. Por isso trouxe para vocês uma receitinha para espantar os mosquitos da sua casa. Bora lá Receita Espanta mosquito Ingredientes: 500 mL de álcool de cereais ou álcool 70 % 10g de cravo-da-índia. 10 gotas de óleo essencial de citronela 10 gotas de óleo essencial de lavanda 1 borrifador Modo de preparo 1. Coloque os cravos-da-índia dentro de um frasco com álcool de cereais. 2. Deixe a mistura descansar por pelo menos 24 horas, agitando de vez em quando. 3. Após esse período, coe os cravos e adicione os óleos essenciais de citronela e lavanda. 4. Despeje o líquido em um borrifador e aplique nos cômodos da casa, especialmente perto de janelas e portas. E Adeus mosquitos 😎

@ 15a592c4:e8bdd024

"Suffering has been stronger than all other teaching, and has taught me to understand what your heart used to be. I have been bent and broken, but – I hope – into a better shape." – Charles Dickens Suffering is an inevitable part of life, and it can be a transformative experience that teaches us valuable lessons. While it's natural to try to avoid pain and hardship, embracing suffering as a teacher can help us grow, learn, and rise above our challenges. In this article, we'll explore the lessons that only suffering can teach. Lesson; 1. Resilience and Adaptability Suffering teaches us to be resilient and adaptable in the face of adversity. When we're forced to navigate difficult circumstances, we learn to adjust our expectations, priorities, and strategies. This adaptability helps us develop coping mechanisms and bounce back from setbacks. 2: Empathy and Compassion Suffering gives us a deeper understanding of others who are struggling. When we've experienced pain and hardship ourselves, we're more likely to empathize with others who are going through similar challenges. This empathy fosters compassion, kindness, and a stronger sense of community. 3: Gratitude and Appreciation Suffering helps us appreciate the good things in life and cultivate gratitude. When we've faced hardship, we're more likely to cherish the people, experiences, and moments that bring us joy. This gratitude shifts our focus from what's lacking to what we already have. 4: Self-Awareness and Introspection Suffering prompts us to look inward and confront our own strengths, weaknesses, and motivations. Through introspection, we gain a deeper understanding of ourselves, our values, and our goals. This self-awareness helps us make positive changes and grow as individuals. 5: Hope and Perseverance Suffering teaches us to hold onto hope, even in the darkest moments. When we've faced adversity and come out the other side, we develop a sense of perseverance that helps us push through challenges. This hope and perseverance give us the strength to keep moving forward, even when the road ahead seems uncertain. Conclusion Suffering is an inevitable part of life, but it can also be a transformative teacher. By embracing the lessons that suffering can teach us, we can rise above our challenges, grow as individuals, and develop the resilience, empathy, gratitude, self-awareness, and hope that we need to navigate life's ups and downs.

@ 15a592c4:e8bdd024

*Strategies for Effective Time Management and Productivity* In today's fast-paced world, managing time effectively is crucial for achieving success in both personal and professional life. With numerous tasks competing for our attention, it's easy to get bogged down and lose focus. However, by implementing the right strategies, you can optimize your time management skills, boost productivity, and accomplish your goals. *Set Clear Goals* Before you can manage your time effectively, you need to know what you want to achieve. Setting clear goals helps you focus on what's truly important and allocate your time accordingly. Try to set SMART (Specific, Measurable, Achievable, Relevant, and Time-bound) goals that align with your priorities. *Use a Scheduling Tool* A scheduling tool, such as a planner, calendar, or app, helps you organize your tasks, appointments, and deadlines. Write down all your tasks, big and small, and allocate specific time slots for each. Set reminders and notifications to ensure you stay on track. *Prioritize Tasks* Not all tasks are created equal. Prioritize tasks based on their urgency and importance. Use the Eisenhower Matrix to categorize tasks into four quadrants: 1. Urgent and important (Do first) 2. Important but not urgent (Schedule) 3. Urgent but not important (Delegate) 4. Not urgent or important (Eliminate) *Avoid Multitasking* Multitasking may seem like an efficient way to get things done, but it can actually decrease productivity and increase stress. Focus on one task at a time, and give it your undivided attention. *Manage Distractions* Distractions are everywhere, from social media to email notifications. Identify your most significant distractions and eliminate them while you work. Use tools like website blockers or apps that help you stay focused. *Take Breaks* Taking regular breaks can help you recharge and maintain productivity. Use the Pomodoro Technique: work for 25 minutes, take a 5-minute break, and repeat. *Learn to Say No* Don't take on too much by trying to please everyone. Learn to say no to tasks that don't align with your goals or values. Remember, saying no to something that doesn't serve you means saying yes to yourself. *Review and Adjust* Regularly review your time management strategy to identify areas for improvement. Adjust your schedule, goals, and habits as needed. Effective time management and productivity require discipline, intention, and strategy. By implementing these strategies, you'll be able to: - Achieve your goals - Reduce stress and anxiety - Increase productivity and efficiency - Enjoy a better work-life balance Remember, time management is a skill that takes practice, so be patient and persistent. With the right strategies and mindset, you can master your time and unlock your potentials...

@ 97c70a44:ad98e322

When developing on nostr, normally it's enough to read the NIP related to a given feature you want to build to know what has to be done. But there are some aspects of nostr development that aren't so straightforward because they depend less on specific data formats than on how different concepts are combined. An example of this is how for a while it was considered best practice to re-publish notes when replying to them. This practice emerged before the outbox model gained traction, and was a hacky way of attempting to ensure relays had the full context required for a given note. Over time though, pubkey hints emerged as a better way to ensure other clients could find required context. Another one of these things is "relay-based groups", or as I prefer to call it "relays-as-groups" (RAG). Such a thing doesn't really exist - there's no spec for it (although some _aspects_ of the concept are included in NIP 29), but at the same time there are two concrete implementations (Flotilla and Chachi) which leverage several different NIPs in order to create a cohesive system for groups on nostr. This composability is one of the neat qualities of nostr. Not only would it be unhelpful to specify how different parts of the protocol should work together, it would be impossible because of the number of possible combinations possible just from applying a little bit of common sense to the NIPs repo. No one said it was ok to put `t` tags on a `kind 0`. But no one's stopping you! And the semantics are basically self-evident if you understand its component parts. So, instead of writing a NIP that sets relay-based groups in stone, I'm writing this guide in order to document how I've combined different parts of the nostr protocol to create a compelling architecture for groups. ## Relays Relays already have a canonical identity, which is the relay's url. Events posted to a relay can be thought of as "posted to that group". This means that every relay is already a group. All nostr notes have already been posted to one or more groups. One common objection to this structure is that identifying a group with a relay means that groups are dependent on the relay to continue hosting the group. In normal broadcast nostr (which forms organic permissionless groups based on user-centric social clustering), this is a very bad thing, because hosts are orthogonal to group identity. Communities are completely different. Communities actually need someone to enforce community boundaries, implement moderation, etc. Reliance on a host is a feature, not a bug (in contrast to NIP 29 groups, which tend to co-locate many groups on a single host, relays-as-groups tends to encourage one group, one host). This doesn't mean that federation, mirrors, and migration can't be accomplished. In a sense, leaving this on the social layer is a good thing, because it adds friction to the dissolution/forking of a group. But the door is wide open to protocol additions to support those use cases for relay-based groups. One possible approach would be to follow [this draft PR](https://github.com/coracle-social/nips/blob/60179dfba2a51479c569c9192290bb4cefc660a8/xx.md#federation) which specified a "federation" event relays could publish on their own behalf. ## Relay keys [This draft PR to NIP 11](https://github.com/nostr-protocol/nips/pull/1764) specifies a `self` field which represents the relay's identity. Using this, relays can publish events on their own behalf. Currently, the `pubkey` field sort of does the same thing, but is overloaded as a contact field for the owner of the relay. ## AUTH Relays can control access using [NIP 42 AUTH](https://github.com/nostr-protocol/nips/blob/master/42.md). There are any number of modes a relay can operate in: 1. No auth, fully public - anyone can read/write to the group. 2. Relays may enforce broad or granular access controls with AUTH. Relays may deny EVENTs or REQs depending on user identity. Messages returned in AUTH, CLOSED, or OK messages should be human readable. It's crucial that clients show these error messages to users. Here's how Flotilla handles failed AUTH and denied event publishing:  [LIMITS](https://github.com/nostr-protocol/nips/pull/1434) could also be used in theory to help clients adapt their interface depending on user abilities and relay policy. 3. AUTH with implicit access controls. In this mode, relays may exclude matching events from REQs if the user does not have permission to view them. This can be useful for multi-use relays that host hidden rooms. This mode should be used with caution, because it can result in confusion for the end user. See [Triflector](https://github.com/coracle-social/triflector) for a relay implementation that supports some of these auth policies. ## Invite codes If a user doesn't have access to a relay, they can request access using [this draft NIP](https://github.com/nostr-protocol/nips/pull/1079). This is true whether access has been explicitly or implicitly denied (although users will have to know that they should use an invite code to request access). The above referenced NIP also contains a mechanism for users to request an invite code that they can share with other users. The policy for these invite codes is entirely up to the relay. They may be single-use, multi-use, or require additional verification. Additional requirements can be communicated to the user in the OK message, for example directions to visit an external URL to register. See [Triflector](https://github.com/coracle-social/triflector) for a relay implementation that supports invite codes. ## Content Any kind of event can be published to a relay being treated as a group, unless rejected by the relay implementation. In particular, [NIP 7D](https://github.com/nostr-protocol/nips/blob/master/7D.md) was added to support basic threads, and [NIP C7](https://github.com/nostr-protocol/nips/blob/master/C7.md) for chat messages. Since which relay an event came from determines which group it was posted to, clients need to have a mechanism for keeping track of which relay they received an event from, and should not broadcast events to other relays (unless intending to cross-post the content). ## Rooms Rooms follow [NIP 29](https://github.com/nostr-protocol/nips/blob/master/29.md). I wish NIP 29 wasn't called "relay based groups", which is very confusing when talking about "relays as groups". It's much better to think of them as sub-groups, or as Flotilla calls them, "rooms". Rooms have two modes - managed and unmanaged. Managed rooms follow all the rules laid out in NIP 29 about metadata published by the relay and user membership. In either case, rooms are represented by a random room id, and are posted to by including the id in an event's `h` tag. This allows rooms to switch between managed and unmanaged modes without losing any content. Managed room names come from `kind 39000` room meta events, but unmanaged rooms don't have these. Instead, room names should come from members' NIP 51 `kind 10009` membership lists. Tags on these lists should look like this: `["group", "groupid", "wss://group.example.com", "Cat lovers"]`. If no name can be found for the room (i.e., there aren't any members), the room should be ignored by clients. Rooms present a difficulty for publishing to the relay as a whole, since content with an `h` tag can't be excluded from requests. Currently, relay-wide posts are h-tagged with `_` which works for "group" clients, but not more generally. I'm not sure how to solve this other than to ask relays to support negative filters. ## Cross-posting The simplest way to cross-post content from one group (or room) to another, is to quote the original note in whatever event kind is appropriate. For example, a blog post might be quoted in a `kind 9` to be cross-posted to chat, or in a `kind 11` to be cross-posted to a thread. `kind 16` reposts can be used the same way if the reader's client renders reposts. Posting the original event to multiple relays-as-groups is trivial, since all you have to do is send the event to the relay. Posting to multiple rooms simultaneously by appending multiple `h` tags is however not recommended, since group relays/clients are incentivised to protect themselves from spam by rejecting events with multiple `h` tags (similar to how events with multiple `t` tags are sometimes rejected). ## Privacy Currently, it's recommended to include a [NIP 70](https://github.com/nostr-protocol/nips/blob/master/70.md) `-` tag on content posted to relays-as-groups to discourage replication of relay-specific content across the network. Another slightly stronger approach would be for group relays to strip signatures in order to make events invalid (or at least deniable). For this approach to work, users would have to be able to signal that they trust relays to be honest. We could also [use ZkSNARKS](https://github.com/nostr-protocol/nips/pull/1682) to validate signatures in bulk. In any case, group posts should not be considered "private" in the same way E2EE groups might be. Relays-as-groups should be considered a good fit for low-stakes groups with many members (since trust deteriorates quickly as more people get involved). ## Membership There is currently no canonical member list published by relays (except for NIP 29 managed rooms). Instead, users keep track of their own relay and room memberships using `kind 10009` lists. Relay-level memberships are represented by an `r` tag containing the relay url, and room-level memberships are represented using a `group` tag. Users can choose to advertise their membership in a RAG by using unencrypted tags, or they may keep their membership private by using encrypted tags. Advertised memberships are useful for helping people find groups based on their social graph:  User memberships should not be trusted, since they can be published unilaterally by anyone, regardless of actual access. Possible improvements in this area would be the ability to provide proof of access: - Relays could publish member lists (although this would sacrifice member privacy) - Relays could support a new command that allows querying a particular member's access status - Relays could provide a proof to the member that they could then choose to publish or not ## Moderation There are two parts to moderation: reporting and taking action based on these reports. Reporting is already covered by [NIP 56](https://github.com/nostr-protocol/nips/blob/master/56.md). Clients should be careful about encouraging users to post reports for illegal content under their own identity, since that can itself be illegal. Relays also should not serve reports to users, since that can be used to _find_ rather than address objectionable content. Reports are only one mechanism for flagging objectionable content. Relay operators and administrators can use whatever heuristics they like to identify and address objectionable content. This might be via automated policies that auto-ban based on reports from high-reputation people, a client that implements [NIP 86](https://github.com/nostr-protocol/nips/blob/master/86.md) relay management API, or by some other admin interface. There's currently no way for moderators of a given relay to be advertised, or for a moderator's client to know that the user is a moderator (so that they can enable UI elements for in-app moderation). This could be addressed via [NIP 11](https://github.com/nostr-protocol/nips/blob/master/11.md), [LIMITS](https://github.com/nostr-protocol/nips/pull/1434), or some other mechanism in the future. ## General best practices In general, it's very important when developing a client to assume that the relay has _no_ special support for _any_ of the above features, instead treating all of this stuff as [progressive enhancement](https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement). For example, if a user enters an invite code, go ahead and send it to the relay using a `kind 28934` event. If it's rejected, you know that it didn't work. But if it's accepted, you don't know that it worked - you only know that the relay allowed the user to publish that event. This is helpful, becaues it may imply that the user does indeed have access to the relay. But additional probing may be needed, and reliance on error messages down the road when something else fails unexpectedly is indispensable. This paradigm may drive some engineers nuts, because it's basically equivalent to coding your clients to reverse-engineer relay support for every feature you want to use. But this is true of nostr as a whole - anyone can put whatever weird stuff in an event and sign it. Clients have to be extremely compliant with Postell's law - doing their absolute best to accept whatever weird data or behavior shows up and handle failure in any situation. Sure, it's annoying, but it's the cost of permissionless development. What it gets us is a completely open-ended protocol, in which anything can be built, and in which every solution is tested by the market.

@ 2ed3596e:98b4cc78

Americans can now Dollar Cost Average (DCA) bitcoin directly from their bank straight to self-custody! This first-of-its-kind product is the safest way to buy bitcoin on a schedule. We call it **Recurring Buy**.  When you set up a Recurring Buy, we handle the entire buying process for you. The journey from dollars in your bank to bitcoin in self-custody is seamless and eliminates the risk of having money sit in a balance at a bitcoin exchange.  Bitcoin Well will automatically pull dollars from your bank, convert them to bitcoin and send your (real) bitcoin directly to your personal wallet. All Recurring Buy transactions have no added fees and we also pay your miner fee. We apply our standard 1.2% spread with no other fees. Your path to financial independence just got automated! 🗓️🤖 To set up your bitcoin Recurring Buy, go to the [Buy bitcoin page](https://app.bitcoinwell.com/usa/buy) and set your purchase size, wallet destination and purchase frequency. That’s it! Watch your self-custody bitcoin wallet fill up with bitcoin. \ \ Below are detailed instructions on how to DCA bitcoin to your personal bitcoin wallet; automatically and on your schedule.  ## **Set your transaction details**   Go to your [Buy bitcoin page](https://app.bitcoinwell.com/usa/buy) where you’ll see four options to set your bitcoin Recurring Buy: Amount, Source, Destination and Frequency.  You can set up to five unique Recurring Buys. This enables you to buy different amounts of bitcoin on different time frames concurrently, all while being sent directly to self-custody for *free* 🤯 <img src="https://blossom.primal.net/49ccbdf5992af9a1ccf3ab2e6dccea33d53f44eb8e31f7bb67abb650518b7d8d.png"> \ **Amount**: Select the amount of dollars you want to convert into bitcoin.  \ \ **Source**: The bank to pull dollars.\ \ **Destination**: Your personal bitcoin wallet. Bitcoin Well automatically converts incoming dollars to bitcoin immediately when they are received. Your bitcoin will be [automatically batched and sent to you for free](https://bitcoinwell.com/blog/bitcoin-transactions-are-now-batched-in-the-usa-heres-what-that-means-for-you).  **Frequency**: Your purchase frequency is set to ‘One time’ by default so you can smash buy.  You can set your payment frequency to weekly, biweekly or monthly. When setting your frequency, choose the start date: you can select “Today” or navigate the calendar to choose a later start date. <img src="https://blossom.primal.net/8023dccf220ca22bcebc7e10ec727311e33a3e19b9fc795ee6a90df7f98317fd.png"> \ Once you’ve set up your Recurring Buy, select “Review” and then “Confirm” to activate your bitcoin Recurring Buy. The best bitcoin Recurring Buy in the USA is here 🐐 ## **Pausing, cancelling or changing your Recurring Buy** \ You can easily pause or cancel any of your Recurring Buys from the Buy bitcoin page. All of your Recurring Buys will be shown on the right-hand side of your Buy bitcoin page on desktop or at the bottom of your Buy bitcoin page on mobile. \ \ To pause a Recurring Buy, click the pause button within the Recurring Buy preview in your Buy bitcoin page. Similarly, to cancel a Recurring Buy, click the ‘Cancel’ button within the Recurring Buy preview. \ \ To replace an active Recurring Buy, simply cancel your active Recurring Buy as described above and then set up a new Recurring Buy with your new desired amount and frequency. For example: you want to cancel an existing biweekly $200 Recurring Buy with a weekly $100 Recurring Buy. Cancel the existing biweekly $200 Recurring buy, then set up a new weekly $100 Recurring Buy as described in **Set your transaction details**. <img src="https://blossom.primal.net/da4919fc378950a29d7bbb05144323b64c0673fbfb846fb3647188f3e817db1d.png"> \ As always, your bitcoin is automatically purchased at the current market rate when your dollars arrive. Additionally, your bitcoin will be batched and sent out on the blockchain *for free* by default.  ## **Earn sats from your bitcoin transactions** \ Bitcoin Well is also the best place in the world to earn bitcoin. When you earn points in your Bitcoin Well account, you gain the opportunity to play the Bitcoin (Wishing) Well, where you win sats with every play. The best part? We send bitcoin that you win straight to your personal wallet via the Lightning Network ⚡ Oh yeah, did we mention you can win 1,000,000 sats? If you're an active Bitcoin Well customer, there is a chance you've earned a pile of points. The more you use your account for buying, selling or spending bitcoin - the more points you’ll earn! Log in to your Bitcoin Well account and [check your point balance](https://app.bitcoinwell.com/reward-points). ## **About Bitcoin Well** \ Bitcoin Well exists to enable independence. We do this by coupling the convenience of modern banking, with the benefits of bitcoin. In other words, we make it easy to use bitcoin with self-custody.  ⁠ ⁠