Longform._ v0.2.30
Continuing support for highlights, yours are now displayed on their respective articles (in purple ofc).
Here’s an example from one of nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc's posts.
https://www.longform.space/reader/_%40dergigi.com/1680612926599
nostr:note1qpaerwvfj3ut5daq8g3a87q2nrt4yc8esjsqxedp2rxc086tn0hqc3e083
"Type 1 events" ????
Wtf nostr:npub1dergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsh9xzpc
Zap axe of ostrich
+ 1 - 20 lightning damage
+ 2 dexterity
+ 1 to head in the sand skill (cowards only)
It needs to download the language packages. For me i notice it does so automatically whenever i encounter a new language, but perhaps some permission stuff is preventing that on your end?
Yeah well that is the case in d2; the pre en sufixes describe the set of attributes, and then those stats have ranges.
The point of the prefixes and sufixes is that you are able to get some coherence in your items such that the attributes are not randomely all over the place, but fit characters/playstyles.
As for them being individual events...i dont know what construct you have in mind, but i concluded probably better to have them as bit encoded strings inside a character or stash state event and let the engine figure out what they are.
using this i was able to vibe code a diablo/path of exile-style loot system. it can run millions of simulations in under a second.
a nostr mmorpg or arpg might be fun... what if item drops could be minted as nostr notes with verifiable randomness 🤔
https://jb55.com/s/4379d654da44f249.txt
nostr:note1gz7m3jesy80yfj4q97h5nctelvxqartdxww2rjyf9nkte5l9z8zqjm7squ
There are some interviews with the guy who did the itemization of D2, forgot his name. Iirc system there is based on sufixes and prefixes.
Of all the arpg's i personally think D2 did the best job for the most part, although im sure it does not jive well with 'modern players'
And it is gloriously stupid, especially in this context
This retarded AI banner on Fiatjafs profile is the best thing ever. I am sure he likes it very, very, very much. Such a good reflection of his upbeat and joyfull character.
I really am too lazy huh...i have a half done video on this very subject, gues i will have to finish it asap to drive the point home
Images is not my domain, but it would make sense to ask photographers or other people in that realm what the type of features they can think off that leverage kind20 tags data which could be implemented in kind20 clients to suit their needs.
I disagree with "keep nostr client implementation simple" to begin with, in the sense that you could just choose to opt for a simple (half-assed, feature poor) implementation of kind, rather than encouraging a shitty practice that undermines feature rich specific clients.
nostr:npub1qe3e5wrvnsgpggtkytxteaqfprz0rgxr8c3l34kk3a9t7e2l3acslezefe another cycling nutjob.
(To be clear, i am not one of you, please leave me alone, i don't even own a bike)
Excuse me, please explain how you make use of the internet without your IP concerns and at the same time not using TOR, i am indeed curious
So you don't use the internet at all, ok, got it.
As you can read in the announcement, relays that are not in your list are connected to via Tor, so that should cover your IP worries.
The websocket handshake overhead should not be too much of a concern in terms of data consumption, as to how redundant the data that is being pulled in i can't comment, but even then, its just a bunch of text/json so are those bytes/kilobytes really that much of a problem to you?
Finaly, i really think you should read up on how Nostr actually works, all those relay connections are in order to fetch the events you want to read, it has nothing to do with where you publish; and regardless, if you want to rely on your own relay, you above all should want people to use this new version of amethyst.
Bitcoin is not censorship resistant you say.
Sorry, i was not aware, silly me.
Can you point me where the state is in controll of Bitcoin? As far as i am aware its just states using BTC...and...well..you know, hard to stop a state from using BTC since censorship resistance was the whole point.
Come to think of it, States are basically the #1 market fit when it comes to censorship resistance; you know, with geo-politics, actuall fucking armies, sanctions and shit going on on that level.
And it so happens that me, lonely individual get to enjoy that same censorship resistance, pretty wild when you think of it🤔.
Bitcoin really is awesome, isn't it😉
Well, they are not random, they are locations the stuff is located where appearently the stuff you want to see is stored.
What is your objection to connecting to '200 random relays'?
What you innitially stated is simply not how Nostr can be expected to work. The possibility that other relays take over your events is not excluded, its simply also not something you should reasonably rely on. Event propagation is more like a marginal quirk than anything else, and unnecessary in case of clients with decent inbox and outbox implementation anyway.
This new version of amethyst is a big step for the Nostr ecosystem
I wouldnt know, i have a bunch of semi-throwaway keypairs on amethyst without back-up that i need to safeguard first before removing the playstore version.
So i will have a look tomorrow or something like that
#Amethyst v1.00.0: Full Outbox
This version completes our migration to the outbox model, where the app dynamically manages the relay list used to pull posts from your follows' own relay lists. By default, the app will connect to relays that aren't in your lists through our embedded Tor. Normal usage will connect to hundreds of relays. Many of them will fail, and that's ok. Nostr has baked-in redundancy; these failures won't affect your experience.
New relay lists were added to the UI to help you manage how the app works. Specifically, you can now block relays and add trusted relays. Trusted relays will connect outside of Tor, which is faster, but allows those relays to see your IP. You should only add relays there if you trust the relay operator. Proxy relays (like filter.nostr.wine) can be added to the proxy list. After that, the app will only use those relays to download the content for your feeds, disabling the outbox model. DMs and other non-outbox functionality will still use their own relays. Broadcasting relays can be added to push your events out there. Every new event from the app will be sent to all broadcasting relays. Finally, the new Indexer list allows you to choose which relays to use to find users, like purplepages.es.
For users of our Quartz library, we have finished all of the work to change the library's mindset from a fixed list to a dynamic pool of relays. Now, each NIP has its own dedicated folder and defines its own tags and caching structures. This expansion allows us to add diverse functionalities such as relay clients, relay servers, event builders, Nostr filter builders, caching systems, deletion and event hint indexers, helper functions, and more—all specifically tailored to each individual NIP. This modular approach creates the space to develop each NIP independently and integrate them into Amethyst as distinct modules, while still sharing Amethyst's main relay and cache engine when necessary. We expect fewer breaking changes as we move forward with it. At some point, Quartz will move to its own repository and be converted to a Kotlin Multiplatform project for each NIP/module. This will allow us to build demo/testing applications for each NIP in the same repo.
This version adds support for:
- YakBak Voice Messages
- Picture-in-Picture pop-ups
- Public Messages
- Coolr.chat's Ephemeral Chats
- Follow packs
- Reads feed in the discovery tab
- Hidden cashu tokens in emojis
Features:
- Reengineered relay, relay pool, and nostr client to manage dynamic pools
- Reengineered note cache for a garbage collector-friendly version
- Reengineered media pre-loading and caching to minimize layout changes
- Reengineered decryption cache, now per account
- Reengineered chat channels cache
- Reengineered the indexing of Addresses to data classes
- Reengineered EOSE cache and managers
- Migrates to a Flow-based design for all account information and services
- Migrates to a Compose subscription model for relay filters
- Adds 90-day expiration to all drafts
- Deprecate stringified JSON in favor of tags on user metadata kind 0 events
- Adds support for live events at the top of the feed.
- Migrates Video events to non-replaceable kinds
- Migrates NIP-51 to use NIP-44 encryptions
- Migrates Chat, Community, Location, and Hashtag follows to their own lists
- Migrates to reply with NIP-22 for everything but kind 1s.
- Massively improves relay hint selections
- Removes relay picker when sending new posts
- Removes general relay list (kind3)
- Adds new relay lists: Trusted, Blocked, Proxy, and Broadcasting
- Moves most of the Dialogs to full-screen routes
- Breaks NewPostScreen and ViewModels into Screens and ViewModels for each supporting NIP
- Adds support for creating and replying to NIP-22 geo scope posts
- Performance Improvements by not re-verifying duplicated events
- Adds Content Sensitivity setting to the Security filter screen
- Adds Translation setting to a new screen.
- Extends AsyncImage to correctly use pre-loaded aspect ratio and avoid jitter
- Adds imeta tags for images and urls inside the content of the Classifieds
- Adds new default banner for empty profiles
- Finishes the migration from LiveData to Flow
- Restructures the old static datasource model into dynamic filter assemblers.
- Moves filter assemblers, viewModels and DAL classes to their own packages.
- Creates Composable observers for Users and Notes
- Unifies all Filter Assembler lifecycle watchers to a few classes
- Moves relay authentication to a coordinator class for all accounts in all relays.
- Moves the relay NOTIFY parser to its own coordinator class for all accounts
- Moves the connection between filters and event cache to its own coordinator class
- Adds support for Tor in push notifications
- Isolated Connectivity services, from Compose to Flow
- Isolated Tor services, from Compose to TorService
- Isolated Memory trimming services, from Compose to Flow
- Isolated Image Caching services, from Compose to Flow
- Isolated Video Caching services
- Isolated Logging services
- Isolated NIP-95 Caching services
- Isolated Pokey receiver services
- Isolated OkHttpClient-building services as flows
- Hold off on all DM attachments until the message is sent.
- Adds previews for any number of urls, events, and media uploads on new post screens.
- Adds zap split, zap raiser, and geolocation symbols for DMs and channel messages
- Adds picture upload for NIP-28 metadata
- Adds support for community relays on NIP-28
- Adds a pool of ExoPlayers when multiple videos are playing
- Moves DVM's last announcement restriction from 90 days to 365 days
Quartz:
- Adds a NostrClient with filter and event outbox cache
- Adds a Basic RelayClient and parsers for all relay commands
- Migrates signers from callback to suspending functions
- Migrates event create functions to builders with templates
- Migrates the filter design to a filter per relay
- Migrates hardcoded tag filters in events to the Tag's parser and assembly functions.
- Normalizes all relay URLs
- Formalizes relay hint providers per kind
- Event store support with SQLite
- Reengineered NIP-55 Android signer and its cache
- Reengineered exception handling for signer errors
- Adds support for the Request to Vanish NIP - 62
- Migrates all NIP-51 lists to the new event-tag structure.
- Migrates Drafts and NIP-04 and NIP-17 DMs to the new structure
- Migrates Bookmarks to the new structure
- Migrates NIP-56 to the newest tag structure
- Adds support for nip70 Protected Tags
- Adds full support for nip73 External Content IDs
- Adds support for NIP-48 proxy tags
- Removes the old "datasource" model
- Adds a Bloom-based hint indexer with MurMur hash
- Adds a PoW miner
- Restructures thread helpers for NIP-10
- Migrates Zap splits, zapraisers, subject, alts, and content warning to their own packages.
Dev Team:
- nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
- nostr:npub1nxa4tywfz9nqp7z9zp7nr7d4nchhclsf58lcqt5y782rmf2hefjquaa6q8
- nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5
- nostr:npub1a3tx8wcrt789skl6gg7rqwj4wey0j53eesr4z6asd4h4jwrd62jq0wkq4k
- nostr:npub1e2yuky03caw4ke3zy68lg0fz3r4gkt94hx4fjmlelacyljgyk79svn3eef
Translations:
- Czech, German, Swedish, and Portuguese by nostr:npub1e2yuky03caw4ke3zy68lg0fz3r4gkt94hx4fjmlelacyljgyk79svn3eef
- Dutch by nostr:npub1w4la29u3zv09r6crx5u8yxax0ffxgekzdm2egzjkjckef7xc83fs0ftxcd
- French by nostr:npub106efcyntxc5qwl3w8krrhyt626m59ya2nk9f40px5s968u5xdwhsjsr8fz
- Polish by nostr:npub16gjyljum0ksrrm28zzvejydgxwfm7xse98zwc4hlgq8epxeuggushqwyrm
- Chinese by nostr:npub1gd8e0xfkylc7v8c5a6hkpj4gelwwcy99jt90lqjseqjj2t253s2s6ch58h
- Slovenian by nostr:npub1qqqqqqz7nhdqz3uuwmzlflxt46lyu7zkuqhcapddhgz66c4ddynswreecw
- Thai by nostr:npub1vm0kq43djwdd4psjgdjgn9z6fm836c35dv7eg7x74z3n3ueq83jqhkxp8e
- Bengali by nostr:npub13qtw3yu0uc9r4yj5x0rhgy8nj5q0uyeq0pavkgt9ly69uuzxgkfqwvx23t
- Hindi by nostr:npub1ww6huwu3xye6r05n3qkjeq62wds5pq0jswhl7uc59lchc0n0ns4sdtw5e6
- Spanish by nostr:npub1luhyzgce7qtcs6r6v00ryjxza8av8u4dzh3avg0zks38tjktnmxspxq903
- Hungarian by nostr:npub1ww8kjxz2akn82qptdpl7glywnchhkx3x04hez3d3rye397turrhssenvtp and nostr:npub1dnvslq0vvrs8d603suykc4harv94yglcxwna9sl2xu8grt2afm3qgfh0tp
- Persian by nostr:npub1cpazafytvafazxkjn43zjfwtfzatfz508r54f6z6a3rf2ws8223qc3xxpk
Download: http://amethyst.social
Yeah outbox and all the other features, really cool. Sure sure, going off from all the comments the app crashes, as a true version 1.0 should.
But i am above all in tears that this post is timestamped, and with a bit of luck future historians have no issue interpreting this event data as a source, and they can explicitly reference it directly in their history writings.
🥹
Hard to figure out what you mean precisely, but running off on assumptions the answer is no.
It means that if you only post your own stuff to your own relay, other people using this version of amethyst will get to see your stuff if they follow you, eventhough they never explicitly put your relay into their relay list.
"I quit signing my own publications, and consuming signed publications"
Sounds like a major step backwards to me🤷♂️
Is knots even intented to be ran other people other then just luke himself (or i suppose the pool he manages)
You are both wrong. Its a misconception that Nostr stands for "Notes and Other Stuff Transmitted by Relays", because then it would NOSTR. And its not, it is Nostr. The connection is merely a coincidence, Nostr is just a word, and 'notes and other stuff transmitted by relays' is just a description.
I am not above shaming bitcoiners into Nostr. This is the way
Thinking about it, i don't really bother with conference apps because im not some networking tiger (fuck people, people suck, leave me alone), but in general they offer scheduling and networking right?
If they where to do that Nostr based, i wouldnt even need to download their app, i can use the ones i already use; but the other way around is even better: people downloading the conference app are onboarding themselves onto nostr right then and there, and all the contacts that they generate persist after the conference when they download other clients.
Not sure if this completely alligns with conference organizing incentives, but frankly stfu we are saving the web over here....get with it.
I get the feeling Bitcoin conferences more or less tollerate Nostr stuff, but thats about it; and if there is no vigilant group of Nostriches pushing for it, nothing is going to come of it and even then it does not really rise above being a marginal afterthought.
Its not a critique, we are not owed anything, just an observation.
Im not familiar enough with that whole industry to know what incentives are at play, but i guess it has to do something with paying bills and an open protocol by itself not doing much of that.
So, where could be the value add for them? A nostr based conference app?
Wait...first this fake lady says Nostr, but then she says Nostr, to end by saying Nostr again. Very confusing. Personally i say Nostr, but i dont mind other people saying Nostr, although generally i do prefer people being consistent in whether they say Nostr of Nostr, instead of switching between Nostr and Nostr willy nilly.
Gigi mentioned nip03 in his post, so 'this' case.
Don't know if its the third thing. Originally the NIP sucked, until i proposed a more sensible idea. Vastly under utilized imo
My go to is the computational inefficiencies of certain systems, and how some bits just needlesly travel the world from register to register wondering when it ever finds its destination.
What are you running up against?
The wiki-page uses a rather broad and vague definition:
"A federation is a group of computing or network providers agreeing upon standards of operation in a collective fashion. "
Still, even then, i would object, the whole notion of federation is mostly Server Oriented Architecture related. Saying that because relays all share the understanding of same set of simple queries makes them federated is too much of a stretch. It might just be straight up incorrect if we start to wonder if relays are even ''a group of computing or network providers''. They don't do any compute, and they don't provide access to a network, they just provide access to data; the only logic going on in a relay is read/write access control.
It is kinda the whole point of Nostr, so I am easily agitated when i see indications of misunderstanding.
I have a similar gripe with the use of ''p2p'' in Bitcoin. People, on-chain bitcoin transactions are NOT peer to peer; miners are not your peers, they are intermediators. Now they are trust minimized and that so happens the be where the whole crux of this Bitcoin system resides; but if one says:
''Yeah well that is what i mean when i tell people Bitcoin has no intermediaries'', then i can't be sure if that is indeed what you mean, or that you missed the whole point all together and actually have all kinds of silly beliefs like that replace by fee is evil or that Nostr relies on federation.
Most of what platforms can't copy is the second order interoperability/horizontal network effects. In terms of first order its most likely censorship resistance which is valuable for all kinds of reasons people simply will never comprehend.
Some dude leading his tribe through trials and tribulations to some milk and honey distribution center
What on earth is a "full relay"??? Also apps dont rely on relays, users do. I am concluding you simply dont understand Nostr
Ha! I was unaware, nice. I wanted to build something that did not need a special NIP to work and in theory could be modified by anyone. The game then itself opens up all these questions about relays, filtering and global state.
And the award to first vandal goes to nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac, scribbling his comments in the library book!
I though maybe creating followpacks that specify all the npubs you want in the story could be a way to filter things🤔
nostr:nevent1qqsxda0mhqv25amgpkex7k3smwlh8n40rch4algz0hdac2z0el7aswcm9uchf