The scrapscript ecosystem needs an elegant alternative to the modern internet’s hodgepodge distaster of authentication, tracking, and payments. Any thoughts?
Authentication:
Asymmetric keypairs and HMAC signatures. Every entity that’s providing a service, be it creating code, hosting, cutting releases, etc. needs to be signed with a key. Keys should be distributed the same way code is distributed (probably via Scrapyards).
Tracking:
Don’t.
Payments:
Someone else’s problem. Payments should at most be a collection of libraries and services. “Web3” crypto stuff is a great way to not be taken seriously outside of very small insular bubbles, but it’s also the only way to do “payments” in a way that isn’t centralized and regulated for now. If you really want to do it, make sure it’s optional, and follows any open standards.
Ha, yes – I completely agree.
When I mentioned “tracking”, I was specifically thinking of ways to reduce tracking across the system.
For example, you mentioned “signing everything” via HMAC. Would that lead to any adverse tracking scenarios for users? Would centralized maintainers of scrapyards and scrap maps be able to farm IP information?
I don’t have answers for any of this haha. I just want to be sure that we’re thinking of the second-order effects of our architecture 
I think I agree. This is just one of those things that I want to pause and ask, “is there anything we can add or remove to the core language to make 3rd-party payments easier or more secure or more private in the future?”
The answer is probably “someone else’s problem”, but I think it’s worthwhile to ask!
You’re pretty much never going to be able to avoid IP tracking info, it’s just not feasible to anonymize it completely. VPNs and proxies mostly solve this problem from the user side too, but most won’t care about the little amount of info an IP leaks.
Also what’s a scrapmap?
IMO Scrapyards should have exactly the same validation structure as users and shouldn’t actually host much, if any ‘unique’ content. Any Scrapyard can host any set of metadata or code. Everything piece of served content gets validated by keys that exist in a decentralized DHT/IPFS space. Information that is produced by the scrapyard itself gets signed with the scrapyards key, but there shouldn’t be much.
If you want to have a federated/semi-centralized approach, you can have Scrapyards themselves replace the role of DHT and delegate trust to the Scrapyard. In that model, instead of having all users keys exist in distributed keyspace, you have the Scrapyard maintain a list of users (probably namespaced to the domain of the Scrapyard) and have it sign the users keys. This is sort of the model that BlueSky uses to validate and sign users information.
Having a strong identity model is the best thing you can do to facilitate payments. The rest is establishing libraries or canonical metadata/protocols for Scrapyards and individuals to communicate how they would like to be paid and allow for gating access to things behind a validated paywall (if you want to be able to have people pay for access to a Scrapyard, for example).
The key is identity and open protocols.
1 Like
This is exactly what I was thinking of! The scrapyard’s namespace is what I call the “scrapmap” (still looking for a better name haha).
So here’s an example of a scrapyard key/value pair:
/sha1/e4cae... : x . x = 42
The x . x = 1 part should be stored as flat scrap bytes.
Here’s an example of the scrapmap, or whatever you want to call the federated namespace:
/ngp/forty-two : [(signed-by-ngp (2023-07-04T17:11:42.682Z, "/ngp/forty-two", just "sha1/e4cae..."))]
Updates to ngp/forty-two can be prepended to the array. The [0] should always be considered the “active” scrap.
All the keys and namespacing info in the scrapmap can be stored at the top level:
/ngp : [(signed-by-ngp (2023-07-04T17:11:42.682Z, "/ngp", just { email = just "ngp@example.com" }))]
Again, the [0] index is the “active” owner of that keyspace. The scrapmap container can manually prepend values to the array if they want to change owners, etc.