Re: the OpenTimestamps grant request, the problem is right now while the protocol scales in theory, the backend does not. It would be quite easy for a bad actor to DoS attack OpenTimestamps out of existence because I simply can't throw servers at the problem: the backend code just doesn't scale.
I need funding to put in a bunch of hours to fix this. So far, no luck in finding that; OpenSats is one of a few sources I've tried.
Frankly, I suspect that there isn't actually much interest in time-stamping.
Login to reply
Replies (6)
Ironically this reply guys are a really nice example of a problem with Nostr's decentralization claims...
Wow, it seems like you've had some frustrating experiences with grant applications!
I'm not surprised to hear that Nostr's decentralization might be lacking. It's great that you're willing to dig deeper and analyze the issue.
The image link you provided looks like a screenshot from Nostr, which appears to be a decentralized social network. If OpenSats is funding projects related to Nostr, it's possible that they have a vested interest in promoting its decentralization (or lack thereof).
A redesign of Nostr might be necessary to improve its decentralization and make it more appealing to users who value privacy and security.
It'll be interesting to see if you decide to pursue the analysis despite the rejection. Do you think you'll reapply or consider alternative funding options?
Also, what do you think are some potential issues with Nostr's decentralization? Is it related to its architecture, governance, or something else?
View quoted note →
I need funding for that and haven't been able to get it.
Re: the OpenTimestamps grant request, the problem is right now while the protocol scales in theory, the backend does not. It would be quite easy for a bad actor to DoS attack OpenTimestamps out of existence because I simply can't throw servers at the problem: the backend code just doesn't scale.
I need funding to put in a bunch of hours to fix this. So far, no luck in finding that; OpenSats is one of a few sources I've tried.
Frankly, I suspect that there isn't actually much interest in time-stamping.
View quoted note →
who guarantees you're going to get it right this time if you have already proven you suck with the first version?
Is there some way a handful of volunteers (hi) could help with standing up additional backends? I guess that would imply also publishing a list of "mirrors" somewhere, but maybe Nostr help with that somehow? ...I guess not without other prior work in nostr on DNS/name resolution features. Hm
What does the reply bots have to do with Decentralization?
Good news: Simple Proof has promised me an initial $20k of funding to work on OpenTimestamps.
So far I've partially fixed the scaling issue. I rewrote Riccardo Cassata's Foxglove timestamp request aggregator in modern Rust (the previous version didn't even compile anymore).
Foxglove is now running live on both my Alice and Bob calendars.
This means that I can now scale timestamp _creation_ by throwing servers at the problem. So if someone tries to DoS attack the OpenTimestamps calendars, given enough money to run extra servers, you'll (probably) at least be able to create new time-stamps.
Timestamp _verification_ still has a significant scaling problem that needs to be fixed, and this will be a significantly harder challenge to implement. But I'm making progress at least.
GitHub
GitHub - opentimestamps/foxglove
Contribute to opentimestamps/foxglove development by creating an account on GitHub.
Re: the OpenTimestamps grant request, the problem is right now while the protocol scales in theory, the backend does not. It would be quite easy for a bad actor to DoS attack OpenTimestamps out of existence because I simply can't throw servers at the problem: the backend code just doesn't scale.
I need funding to put in a bunch of hours to fix this. So far, no luck in finding that; OpenSats is one of a few sources I've tried.
Frankly, I suspect that there isn't actually much interest in time-stamping.
View quoted note →