Profile: 75d570e6...
that would require changing specs of kinds 0, 1, 20 etc.
"images should be only loaded from HTTP servers that return Content-Length HTTP header or specify Content-Length in imeta metadata"
make Content-Length mandatory in spec. make clients ignore images that do not follow spec.
32B llm model is now better than human average on one of the most difficult benchmarks. i think we are starting go to the exponential growth territory. despite previously commercial models being able to do the same, commercial models are not scalable. when reasonable sized open source models beat human capabilities we are starting to see scalable exponential growth. these models can be deployed in millions.
although in reality, you load profile picture once, you can save whatever quality variant of it in local storage.
if someone wants to waste your bandwidth, they can post single post with 100x 500 MB gifs anyway.
you could add soft recommendations of picture sizes in spec for all images, as well as bandwidth saving setting which prevents automatic loading of images past specified size.
also it could still be beneficial to have two image qualities for all image posts. often its not necessary to load 8K image in feed, but photographer may still want to publish original high quality image.
its possible to specify in kind 0 spec that picture value cannot point to image larger than specific size. its also possible to change spec to specify two images: small and full size.
first they make their html pages so heavy (on the client side, because we dont use php server side processing anymore), then they cant serve 5 MB html blob pages anymore after 5 responses to same ip. but it seems they are so broke 25 MB traffic per ip is definitely killing big tech servers.
have you seen that cool unicorn rate throttling github html page requests after 5 page loads...
big tech is killing itself intentionally
probably flac and opus
nsec simply works, but some popular clients decide not to implement simplest possible #nostr login.
its as secure as anything else when its http://localhost
most of #nostr is #ethereum. its a #pos model, which is a trust model equal to #wot model. both are social trust models, rather than computational trust models.
social trust model is a model where network peers must trust existing peers to provide valid network state, whereas computational trust model is where only computation needs to be trusted. latter is called #pow model.
if you want nostr based, fork plebs.app
https://github.com/Spl0itable/plebs-app
it probably has some features you dont like but its relatively easy to adjust.
if you want fedi based, there is peertube
i mean. this is not really the case.
its not necessary that the past chain is vulnerable to do a double spend attack. you can rewrite the chain after accepted transaction.
all you need is enough fake blocks for someone to accept transaction as complete. 10 blocks? 30 blocks?
thats possible if nodes still validate the pow chain. but this would mean the security diminishes as the pos chain grows longer