-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Questions #10
Comments
Hi @RobStallion, thanks for posting these good questions as an issue. 🎉
Answers1. Uniqueness?
That needs to be clear to everyone from the first line of the readme. We will be using the SHA256 hash which to date has not incurred a single hash collision. 256 bits of data is used by most crypto currencies. Enough "smart people" have done the homework on this for us not to worry about it. The "math" is covered in: https://crypto.stackexchange.com/questions/39641/what-are-the-odds-of-collisions-for-a-hash-function-with-256-bit-output This is the best video on 256 bit hash collision probability: This video does not cover the "Birthday Paradox" see: nelsonic/nelsonic.github.io#576
|
inserted |
cid (PK)1 |
address |
slug |
prev |
---|---|---|---|---|
1541609554 | hdyk80sgPeAX | Wayne Manor, 1007 Mountain Drive, Gotham | hdy | null |
1541618643 | HvTlGsEX88Nc | Wayne Manor, 1007 Mountain Drive, Gotham | waynemanor | hdyk80sgPeAX |
1541628987 | pN7hWNuqJ6J | Wayne Manor, 1007 Mountain Drive, Gotham, USA | waynemanor | HvTlGsEX88Nc |
The first row is the "creation" of the entry for "Wayne Manor".
At this point the URL would be: bnb.com/hdy corresponding to the first 3 letters of the cid
.
The second row is when the listing owner updates the slug
to be a more friendly waynemanor
so the URL is more human memorable and SEO friendly: bnb.com/waynemanor
The URL may be longer but it's more memorable and thus people may prefer it.
Notice how the value of prev
refers to the cid
of the previous version of the record?
that's how we do versioning in a cid
based web app. (see below)
As this data will be stored "centrally" by a PostgreSQL database, the DB can be responsible for ensuring that the slug
field is not duplicated. We will need to run a "SELECT" query before inserting any record that has a slug
to confirm that the user inserting the data has the access rights to update the row with that slug
but we will clarify those "access control" details later. For now, let's stick with the simplified version.
In the third row, we added the "USA" to the address which changed the content and thus creates a new cid
. The prev
refers to the previous version of the record (before "USA" was added). The slug
has not changed, so the URL is still the same: bnb.com/waynemanor
2. Updating Content
the update version of content would be linked to the previous version using a prev
field the way it happens in IPFS, Etherium and Bitcoin (so it will be familiar to people)
prev: previous_cid
address example:
inserted |
cid (PK)1 |
name |
address |
prev |
---|---|---|---|---|
1541609554 | gVSTedHFGBetxy | Bruce Wane | 1007 Mountain Drive, Gotham | null |
1541618643 | smnELuCmEaX42 | Bruce Wane | Rua Goncalo Afonso, Vila Madalena, Sao Paulo, 05436-100, Brazil | gVSTedHFGBetxy |
When a row does not have a prev
value then we know it is the first time that content has been inserted into the database. When a prev
value is defined in a row we know this is a new version of a previously inserted content and we can "traverse the tree" to see all previous versions.
1: all
cid
values truncated for brevity.
@RobStallion please let me know if this answers your questions. 🤔
If not, please help identify the remaining confusion. thanks. 👍
@nelsonic Those are amazing thank you. Super super helpful. 👍 |
@RobStallion do you want to convert these questions & answers into "FAQ.md" and create a PR? 😉 |
@nelsonic Will do 👍 |
The following lines added to the read in #16 answer my first question...
|
Closing as @nelsonic has answered my questions and they have been added to readme |
@nelsonic just opening this issue as a place to ask some questions I have at the moment. Can split each question into their own issue if needed or add them to an FAQ section in the readme if you feel that would be helpful.
Questions
1.
In issue #1 you mention shortening the URL from:
to
How would we ensure that this URL is always unique. If we had millions of URLs, like youtube for example? 4 characters does not seem long enough for that to be possible.
2.
In issue #1 you mention:
My understanding of the above is that we would take all the content from the form submission and hash it generating a string (which would be used as the primary key). The same content would generate the same string so we could easily tell if it existed or not (I think this is similar to how hash tables work under the hood (thanks for suggesting that book btw 😉)). If my understanding of this is correct then my questions are...
How would we link the change to the original? Would we still be using an
alog
approach where we have a:entry_id
to keep track of this?Would the long term plan be to be just track the changes, and link to the original file? (I believe this is similar to how both git and IPFS work)
The text was updated successfully, but these errors were encountered: