#Nostur update (TestFlight)
- Added Hot feed: show posts most liked by people you follow
- Added block person to DM context menu
- Added toggle to temporarily show DMs outside your Web of Trust
- Fixed issue with DMs not loading if WoT is empty
- Fixed own sent DM showing as +1 unread
- Fixed video muting issue
TestFlight: https://nostur.com/testflight
Source code: https://nostur.com/source
Just realized that I was missing Jack from the Hot feed. I found that hard to believe. Then I realized it was because my device didn’t calculate the amount of likes / comments on his posts haha
#Nostur update (TestFlight)
- Added Hot feed: show posts most liked by people you follow
- Added block person to DM context menu
- Added toggle to temporarily show DMs outside your Web of Trust
- Fixed issue with DMs not loading if WoT is empty
- Fixed own sent DM showing as +1 unread
- Fixed video muting issue
TestFlight: https://nostur.com/testflight
Source code: https://nostur.com/source
Nostur getting better every day. New Hot feed, basic algorithm, works great!
And it’s STILL the only iOS app with multi account management
#[0]
DVMs require the user to pay, right? I could see that requirement as a reason to just hardcode some basic algorithms to run on the device at least by default
Can I request that the timeframe go even higher for people that don’t check the app every day? Reddit has Year, Month, Week, Day, and Hour (for comparison)
#Nostur update (TestFlight)
- Added Hot feed: show posts most liked by people you follow
- Added block person to DM context menu
- Added toggle to temporarily show DMs outside your Web of Trust
- Fixed issue with DMs not loading if WoT is empty
- Fixed own sent DM showing as +1 unread
- Fixed video muting issue
TestFlight: https://nostur.com/testflight
Source code: https://nostur.com/source
I was JUST gonna ask about the time frame. Thanks for adding this config!!
📢 NDK 1.0 is out!
Codename: Outbox ✅
When I set out to write NDK my main goal was implementing the gossip protocol, now known as *outbox model*. I wanted nostr applications to have decentralizing tendencies by *default*; transparent to the developer.
After a few failed attempts, it's finally here, which, paired with a bunch of non-backward compatible changes, prompts me to do a major version bump.
# What is outbox model?
In short, the outbox model allows nostr to fragment, instead of everybody coalescing around a few popular relay and using things like Blastr. Nostr simply doesn't work without the outbox model.
# Main changes:
* Outbox model support, obviously.
* `fetchEvent(s)` is now faster, (particularly with queries using exclusively `ids` filters).
* Fixed unstable relay back-off code (credit goes to nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 for the valuable testing infrastructure)
* Defaults to blacklisting wss://brb.io #censorship (credit goes to nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 for the widely hinted-at dead relay)
* Subscription aggregation now works when multiple filters run at the same time
* Subscriptions that should close when EOSEd are now closed when each individual relay EOSEs instead of waiting for all of them to EOSE.
* A better algorithm on when to signal a subscription's EOSE. The margin that NDK now gives to relays to EOSE is now a function of how many of the connected relays in the relay set have EOSEd (accounting for relays that are still sending events).
* There are *many* more changes that I needed to do to accommodate for this that I don't remember now.
Some of the most glaring breaking changes:
* `ndk.subscribe` now defaults to keeping the subscription alive; the default of closing subscriptions on EOSE was bothering me
* NDKUser changes the `hexpubkey` from a function to a getter, so wherever you were using `user.hexpubkey()` needs to change to `user.hexpubkey`.
# Enabling outbox model
Outbox model comes disabled by default *for now*, as soon as I test it more throughogly it will be the default.
To enable it you need to instantiate NDK with:
```
const ndk = new NDK({
explicitRelayUrls: [...],
outboxRelayUrls: ["wss://purplepag.es"],
enableOutboxModel: true,
})
```
The outbox model will largely be transparent to you and will work on the background once you enable it.
Re: Outbox: does this mean that you don’t need to manage relays manually at all? It will just hit the Purple Pages relays (assuming multiple are supported here?) and use whatever is shown there?
They could be, but Coracle’s is definitely worse. Stacking 20 bubbles on top of each other just because I’m naturally clicking on posts while I browse. At least it’s bold
And the pop ups that stack up are strange.
It “works” as a concept but it is not intuitive. There are conventions that users are very accustomed to by now
How are conflicts resolved then? And would this be better to abstract to an NIP for mapping any addressable content to a pub key then? For example a movie page could get a pub key that people could tag? https://www.themoviedb.org/movie/36557-casino-royale
It also doesn’t need any verification, so it can be done without approval of the domain owner.
In that sense, this could be an NIP for linking *anything* to a public key
What can Nostr learn from webring or even the much larger webring Stumble Upon?
DNSTR - Domain Name Mapping for Nostr Public Keys
https://gist.github.com/melvincarvalho/09b8d8dfdb6d89a9043fae26e9312b1e
Is this the same as using an “_” for a username in the NIP5 mapping ?
That’s awesome! This should be a more well known pattern
Nostr has no global. It’s just relays and the data that is posted to them. There is no data replication between relays other than users broadcasting to multiple relays.
It has nothing remotely like Tiktok global data. The closest thing is a huge relay like Primal, and that proves my point that their “global” feed is garbage that is irrelevant to me
Is the idea then that apps will keep their regular database of content outside of Nostr?
That’s an interesting solution to the problem of niche apps. Just simply don’t put the data on Nostr at all. Just use Nostr for accounts and nothing else basically
Tiktok “endless” content because it is global.
Nostr very quickly ends because you basically have content from your friends, then friends of friends. And when you go beyond that, the content is increasingly irrelevant. There is no “global” on nostr.
The problem now is that I feel like I have to scroll everything I missed because I can’t find what is notable or worth reading otherwise. It’s a time sink!!
nostr-one is a beautiful one-line web component that allows login with nostr on any website using just a single tag. Great work from dolu89
Try it here: https://nostr-one.dolu.dev/
Is there a benefit to doing this with zero other nostr usage?
Or is the idea that this is a stopgap before one implements a deeper nostr integration?
It’s hard to articulate the Nostr issue I am experiencing right now.
How do you have multiple apps that each serve a niche purpose without requiring new event kinds for each app?
The p2p server solution is to let each user have their own file directory where they store the different events and data in different directories.
How do you do this in Nostr? We have no such directory structure. It’s all flat. We end up either polluting apps with irrelevant events or having thousands of different event kinds that is unsustainable and unscalable.
Ironically, algorithms is what enables us to use our phones *less*.
Serve the meaningful and important content right away rather than hunting for it