You will fail at moderation like everyone does at a big enough scale, I have seen absolutely no evidence that moderation is scalable, and without scalability you are left with a company raising VC money or Ads to hire more moderators for more users, then the VC or the Ad companies decide what platform you are running.. but we already have that it is called Twitter.

All I see is that people are building Twitter alternatives and hoping that with enough good will the moderation problem is going to go away... it will absolutely not.

That is definitely one way to ignore the data by assuming it is a Bluesky failure... but even then you have to ask; what evidence do you have that you can do better.

If you are dedicating your life to build alternative social media that competes with Twitter, you owe it to yourself to look at this and ask yourself few difficult questions

I agree with this, every protocol that support web apps should think deeply about shipping Web Components for the novel UX it offers. I tried to explore that for Auth with Pubky, and I believe that component is still in the code as an example, but publishing an NPM library of Components would be super cool for apps to build on your protocol easily and avoid the UX paper cuts that you already solved for.

nostr:nevent1qqs2r83ku6twuk4tq6ekuvrknu7mzfk3myty5dpzrlk20lf2sdhdf8spndmhxue69uhkummn9ekx7mp0y5erqamnwvaz7tmwdaehgu3wd3skuep0y5erqffjxpshvct5v9ez2v3swaehxw309ahx7um5wgh8w6twv5hj2v3sy5erqctkv96xzu39xgc8wumn8ghj7ur4wfcxcetjv4kxz7fwvdhk6te9xgc8wumn8ghj7un9d3shjtnyv9kh2uewd9hj7ffjxpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9upzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qvzqqqqqqy0lcrdd

It is easy to make primitives that qualify as private in some definition of privacy, but the full solution that I am talking about and that Peergos has is quite difficult and the incentives for putting that effort is not there in Pubky given that the main app doesn't need it (most features can be satisfied with simpler less disruptive solutions), but it sure needs other things and will compete for resources.

More importantly, unlike the current state of pubky core, if you want to achieve what Peergos does, clients will have to get more complex (to manage Cryptrees, remember that name? :'D), in fact they will get so complex that client side signing will become a no brainer as the simplicity that justifies the current sessions model will go away.

If you still are willing to go that painful route, I think you should contact Ian Preston and ask him to consult for that transformation, since he has been there and done that. And I talked to him enough that he understands what Pubky core is.

Or wait till I get bored enough and start implementing all of this myself and see if there are good ideas there you want to copy.

Best of luck anyways.

It is so pathetic to see westerners saying there is no genocide nor ethnic cleansing when zionists themselves are so comfortable admitting it, either to jump ship, or to actually push for the final solution.

nostr:nevent1qqsf600y885w95qknkrxhw9sfztnujaz9retf9v6a25w4uhpek9g2wcpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqhcagdqsfgk264wvae5mzpkdfsgfw7lwqy3qucaqhvqwtzhaqrldqvzqqqqqqycqas0t

It amazes me that some still talk about zionism as just a neutral ideology... what more do they have to do in order to be recognised as pure evil?

nostr:nevent1qqsgycttm2gxxrn2lfnt89jl9azsca47y0q5dw3jdfwkp3s0nc32ftcpz3mhxue69uhkummnw3ezummcw3ezuer9wcpzqmyv09uma5emjv78thm229309d3jwdzvztjuaex8w0suzq24jhe7qvzqqqqqqyh0umyj

Just playing his role

Praying for 50% crash

Sharing write access is not the only hard part, sharing read access in scalable and UX friendly way is also insanely hard and this "Blossom is fine" won't magically make it fine.

You can't achieve all this client side. You can't build all these features with only the feature set that Blossom provides... the server needs to understand the format you are using to manage this encrypted filesystem to be able do important tasks like storage reclamation and access denial even for things that are encrypted.

I never said we need to build things like Google, I only said Blossom won't cut it, the full access control of read and write and managing that with filesystem semantics in a UX friendly way is hard work that is inherently complex yet I insist it is necessary for most applications and without it you don't have an open cloud platform.

I am not sure what is the disagreement here. My best guess is that you think you can build this on Blossom, I disagree.

I don't know how to argue with "no one asked for it on Nostr yet" when I am asking for them, and literally millions of people are spending arguably too much money for Proton Drive to have exactly what I am asking for but without the open API.

But again, if you don't care, you don't care, ain't no arguing with that.

I am not aware of people self hosting.. but it should be doable it is open source and it should work just fine.

The main downside of peergos is a centralised PKI, but we know how to fix that. And Peergos developers will add something similar to Pkarr eventually.

If i understand correctly encryption and decryption with FROST would be asymmetric.. which is not efficient, it would be fine for sharing the symmetric key... but the hard part isn't encrypting a symmetric key for the target receiver... that the easiest part to be honest.

The hard part is when you need to revoke someone access from an entire directory... and now you need to reencrypt everything on write, and you need to share the new keys to all the remaining members and you need to do all of that from an interface that is not any more complicated than Google Drive sharing settings.

Then you need to delete all the previous chunks of the filesystem tree to reclaim the storage. And if you have a builtin history system things get even harder as new keys should be able to decrypt old files but not vice versa.

I am sorry but these problems need to be solved cohesively otherwise you don't have a platform. Access control is not a plug in on S3, it is inherit and it makes or breaks the platform that became later a standard.

You are wrong, but hey, try it and see if you can build an encrypted filesystem on Blossom without changing Blossom and without asking clients to do prohibitively complex work on their side, and while reclaiming storage from previous overwritten state.

Sure your needs might be limited that you can come up with ad hoc ways to satisfy them with Blossom only and few extra tricks on top, but you can't solve for the general problem without servers helping.

I can write about all the challenges involved in a more coherent manner, but honestly I am not sure anyone cares. So it is one of these things where I have to just build what I want and if people think it is valuable they can help themselves to it.

That being said, even without encryption I think I did a very good job while working on Pubky combining WebDav with cryptographic identity and authentication, and people can use that or learn from it if they want. Or not.

nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnhd9hx2tc42aswu of course, there are apps that cant be built even with a Proton Drive like API. Most notably apps like Twitter or any app that needs aggregation of data authored by multiple people and custom API endpoints that are tailored to the UI needs (backend for frontends) ... but I always argued that these are lost cause.

I just want to see something like Proton Drive but open for all quiet apps to flourish there... I dont want the next Obsidian to be closed source, nor its cloud sync to be centralised.

Good for you, but that is not what I am talking about, encrypting blobs is easy even on client side and a dumb server, but that is too far from an e2e encrypted filesystem where key management, access control and granting and revoking access is neatly packaged in an SDK.

That is what I am talking about and it is the necessary (and sufficient) feature to build any cloud application where the user come with their own storage... I know that because every Google/Proton Drive provider immediately starts offering stuff like Docs and Sheets etc. Because they can.

Now you can use blobs on Blossom to make up a Cryptree like Peergos, but Blossom is not smart enough to help you with access control (beyond encryption, which is imprtant), and not smart enough to handle the difficult key sharing story, and most importantly it is not smart enough to know what nodes in that tree needs to be deleted to reclaim storage.

If you don't feel the need for an e2e2 key value store or filesystem... then you are not building the apps that do, my point was if we are going to build an open storage protocol, might as well build what is necessary and sufficient for any app that is analogous to native apps but with cloud storage instead of local storage, instead of building Blossom then realising it is not good enough later.

As usual, I invite you and others to look at Peergos or just imagine what you would build if every user had a sovereign version of Proton Drive with open API.

Yeah they are alright for public immutable files .. that's what they were designed for and they do well.

But the exact same feature could be achieved with WebDav... so I am not really sure what does Blossom offer more than the ancient and equally simple WebDav... even if you wanted to use nostr keys instead of web fingers or usernames, you could fork a webdav server to support that in a weekend, and you get all the webdav features while at it.

Addressing files by their hashes only serves popular content so people can share it trustlessly ... user storage on the other hand will be shared by no one.. it is only going to be read by the user and those who get links to these files... so what Blossom does doesn't achieve anything but make most apps harder to implement... even WebDav was better.

Even if you manage to build an interface on top of this, it will be horrendous, because you will have to deal with garbage collection on the client side. Because only the client know which blocks no longer needed for the latest version of the state of the filesystem, Blossom itself doesn't have this information... and leaving garbage collection/storage reclamation to applications is not a good idea.

You are under selling the need for ordered key value store or a filesystem interface.

Without this consistency of an ordered yet e2e encrypted lists, plenty of apps are simply impossible, unless you fake it using a mutable file and embed an sqlite file in there, however this will suck ass to maintain AND Blossom doesnt have mutable files at all.

Think; how do you build every app in Google suite or Proton Drive apps without this ability?

Or think instead; why do we have filesystems and BtreeMaps if we can build apps with random immutable files?

Finally; you can't slap privacy on top ... it is the HARDEST part, someone has to build this once for everyone and servers have to be involved.. think of all the access control and key management and defense in depth where servers don't give encrypted files to random people even if they can't decrypt it, because eventually they might be able to... etc.

My point is, Blossom won't cut it. If you insist on using it because the availability bias... fine, but maybe check Peergos to get an idea on what can be done.

I think that is fine. I however don't like the idea of many servers... users (including me) won't enjoy managing all these relationships.

I am not talking about the multiple providers here, for this people can run a mirror on their own device or use a friend as a backup.

I am talking about Blossom being insufficient alternative to Proton Drive or even WebDav... so now if you need end to end encryption and sorted key value store or filesystem semantic... you have to either build that on Blossom only to realise it is a bad design since the server is not doing its part of enforcing access control OR you have to build entirely new kind of servers.

My point is, everything Blossom (or any content addressable chunks server) can do, Proton Drive servers can do, but not the other way around.

So why bother with Blossom at all? Yes they are simpler, but they are not complete and the need for the complete solution doesn't magically disappear just because you wish you didn't need them.

So you tell me, if there was an open alternative to Protons Drive, wouldn't keychat apps benefit from that in ways Blossom can't help with?

The idea that all you need to pass bitcoins to your future self or children is a seed phrase will hurt people. Eventually most nodes will be pruned and you will have to provide the block headers and merkle proofs of your utxos to spend them.

Even if this never happens, you shouldn't depend on strangers for data availability necessary to secure your wealth.

Moreover, most users will never have a utxo at all, so they need to backup their vtxos or other forms of client side validated transaction data to own anything.

Open, secure, durable, and reliable cloud storage protocols and infrastructure are necessary for all kind of applications, but they are necessary for property rights on the Internet too

I just saw an entire company (all official accounts and emplyees) get suspended on Twitter... absolutely insane shit.

Or what? What are you going to do if everyone started calling sats bitcoins?

Well, Bitkit already started, you let me know if the sky falls or if anyone gives a fuck at all.

What we are fighting is apathy. I know Turks bought gold instead of Bitcoins to escape inflation, even when they had to import more on containers after the local supply dried up... so let's not count are chicken before the hatch.

No one fuckin wants to change the decimal point for BTC man, the price charts will not change.

All what people say is just use "bitcoins" where you are currently using "sats".

Anyways, it doesn't matter really 😅

Again, you are just saying that BTC is interchangeable with "bitcoins".

I can accept that argument and the discussion ends after that because I disagree and it is too subjective to settle, and everyone can do what they want going forward.

But I disagree with the last point too, I don't think we will need to divide bitcoins further than the granularity in the code, even though I actually don't think "millisats" are fake, but I just don't think we will have that much economic activity on the Internet flowing through Bitcoin that one unit becomes too expensive.

Anyways, if only these were our biggest problems.

No BTC price will stay the same.

You can tell the "normies" that BTC is a large denomination and that they can afford 1000 bitcoins.

If you think telling them they can afford sats instead... fine, but you have to engage with the fact that "sats" means absolutely fuck all to people.

1. We said 21 million BTC.

2. Telling people that they can't afford any "bitcoin" is bad and needs a solution

If you think the solution is to tell them about this new thing called sats, fine. But let's not pretend that introducing a whole obscure word is better.. "sats" means nothing to anyone unless they already own bitcoin, even then it is iffy.

nostr:nevent1qqstftg7qfltq9kl9jpw7w2pm2lp63ta28uwddn53cfjj4eg2rhkqjqpp4mhxue69uhkummn9ekx7mqzyprqcf0xst760qet2tglytfay2e3wmvh9asdehpjztkceyh0s5r9cqcyqqqqqqgqlxn44

But what I am saying is;

1. We don't have that consensus at all, we only have a consensus on the 21_00_000_000_000_000 units, regardless what they are called, sats or bitcoins.

2. To the extent that the "21 million" meme matters to anyone, it is regarding the token "BTC", not for the lower case bitcoins word.

3. That the negative effect of the unit bias, is way bigger than the positive effect of the 21 meme, even if you insist that the meme is "21M bitcoins" not "21M BTC"

If you disagree with that... fine, people will fight this one out in their app implementations, no one can force anyone to do anything.

Your argument then is that BTC is synonymous with lower case bitcoins.

But a counter argument could be that BTC is distinct from bitcoins, and are usually pronounced bee tee cee.

The only reason this shit matters, if it does matter is that calling BTC bitcoins, instead of calling sats bitcoins, make bitcoin sound extremely unaffordable.

You can argue that normies are retarded for not knowing that BTC is millions of times bigger than what they can actually buy, but that won't help.

I hope people arguing against the bip at least engage with the unit bias argument instead of insisting that the 21 meme has anywhere near the same effect on the general population perception of Bitcoin

No 2. Is wrong. The idea is that BTC is the 100_000_000 thing and remains so.

All people are saying is call sats lower case bitcoins.

I don't care either way. But at least criticise the real suggestion.

I always disliked this idea that relays are good abstraction for feeds... running an entire server just to serve one feed is wasteful.

Let CDNs do their thing, and allow anyone to author feeds that are easily readable with data integrity.

Servers are hard and should be done only once, uploading and updating lists once you have servers is super cheap.

nostr:nevent1qqsd2d3g6wuvuq5g0dpy9dg8jwhguels8ef77rtlp7y3u5cvam37p4gpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzq4maupkuu9s2qdu3vwjtk7mgp037pg8pc6x7de463sq3xj6yqexaqvzqqqqqqyetdf2f