It’s all good, the section key is agreed. Each section is progressing and the section chain network wide is like a tree structure. So we can go back to any point in section time with ease. So no error margin there at all, with the exception we may fork chains rarely and merge back invalidating some recent keys and re-sign data. So there is the possibility of that. Not a big issue I feel as this section time will have very low levels of resolution.
2 Likes
Unclear if section time is linear, so that user can rollback to what they are wanting when - in real time… or if it’s just that the order is there because of section time being ordered.
Yes it’s linear with this sometimes fork / repair caveat (like blockchain can).
203 posts in this thread. Is it time for someone to get out the Post-it notes and start sticking them on the wall yet?
1 Like
Like this?
NRS brainstorm Post-it summary
A summary of the discussion points above which went from the desirability of NRS to the meaning of the perpetual web, to approximating time keeping on Safe. It’s a Wiki so please add, subtract or qualify
What is NRS?
Name Resolution System (NRS) is a system that translates a human-readable web address into a content based 256-bit XOR address. It’s analogous to the Domain Name System (DNS) on the Internet.
XOR addresses (unique identifiers for stored data) can also be translated into more manageable base32-encoded XOR-URLs, but though shorter these are still not easy for people to read. XOR-URLs may also encode metadata such as mime type.
Features of NRS
NRS is an app-layer system rather than a feature of the network itself, meaning it can be replaced by a competitor. However, it is currently part of the MVP feature set.
NRS only translates the address of a domain. It does not encode any metadata.
Websites on the Safe Network can be identified using NRS thus: safe://service_name.public_id
Files on the Safe Network can be identified using NRS thus: safe://service_name.public_id/file?v=[int]. The version number applies to mutable data. When the data is changed the version number increases by 1.
There is arguably a case for enforcing version numbers in NRS links to resources so that the version returned is predictable. There may also be a case for allowing ?v=latest so that the latest version of the file is returned (See below)
Advantages of NRS
Ease of use, people want simplicity.
NRS is a key differentiator.
Can allow simple transactions without copy-pasting long keys
XOR URLs are hard to use for people with visual impairments, scary for the non-technical
Possible business opportunity for MaidSafe selling domains
Disadvantages of NRS
In current form it allows domain squatting
Link rot “For something to be called the ‘permanent web’ it must do more than just store bits, it must have them accessible.” (See below)
NRS is currently the only game in town
The simplicity and tidiness of NRS may encourage unversioned links (See below)
Allows use of visually similar characters and commonly confused characters, homoglyphs etc
Confusion of addressing and ID "There’s an assumption that follows from DNS that public names are unique”.
Other comments
Should priority be search instead of refining NRS?
Competitive NRS could be advantageous.
But could lead to competing incompatible ecosystems.
Possible alternative approaches/enhancements to NRS
Just use XOR-URLs.
Pros: everything is versioned, no squatting, secure. Cons: not user friendly
Don’t use a single global namespace and instead have hundreds or thousands of short-ish TLDs with more that become available over time"
Instead of alphabetic TLDs, you could also use the year
Identity
Title (or Petname) / PublicName combo - a non-unique name to go alongside the PublicName.
“These three elements, Public Name, Site Name, and Pet Name`, are the elements that would allow a site to be Findable, and communicable.”
There can be other ways to check the Public ID of a publisher, including a profile, flags and site page history. Do they pass the smell test?
Link rot
Link rot is where a link to an external resource goes out of date when the version of that resource changes.
“An important difference with Safe is that the destination data doesn’t rot, it’s the link pointing to it that may no longer point to the correct version".
Versioned files might link to CSS stylesheets, JavaScript, and other programs and frameworks that might change in unpredictable ways and may not be backwards compatible.
Possible solutions to link rot
Link to the latest version by default using something like safe:link_to_resource?version=latest.
Insist all NRS links are versioned - i.e. they point to a specific version of the resource, or use XOR-URLs instead of NRS.
Enforce versioning: Safe_api could reject any SafeUrl without a version identifier
Drawbacks to these solutions
Link to latest by default:
Makes the perpetual web difficult to imagine, because a page viewed some time later might show a different embedded image, different text etc, and changes to the external resources are out of our control. “Being able to link to “latest” anything is easier/simpler/cleaner. But we cannot have that and a permanent web as far as I can see at the mo.”
Cannot use dates or relative time to pin version (Safe has no time).
All external links versioned
Could be inflexible:
“Links never go stale on a permaweb.”
“They do, if the intent is to link to the latest version and that not an option.”
The Perpetual Web
The Perpetual Web is a Safe USP, but what do we mean by the Perpetual Web? It needs a clearer definition.
Does it mean:
- Historical pages are strictly immutable and will look and behave in exactly the same way in 20 years time?
- Historical pages will feature the same content but may look and/or behave differently (eg updated CSS/JS)?
- Historical pages will exist forever but the links within them can change?
What proportion of Safe’s users will value the Perpetual Web? Should it be the default setting or an option for archivists, journalists and fact checkers?
If links are made to static versions, how can we be sure that links in the linked documents are also static? What if they link to the latest version of some image? How do we get to the latest version?
If links are by default to the latest version, how to we smoothly roll back to previous versions?
How can a perpetual web and one that’s constantly changing coexist?
Safe should be able to accommodate both the need to snapshot the past and the requirement to keep up with the present. But there are likely lots of edge cases.
Example: a page that presents images at random.
“If there is random behavior at version N, then there should be randomness again 10 years later at version N.”
Where and should these ‘snapshots’ be stored? If a niche use case requires the entire site is saved exactly as is for the historical record, this could be done in private (paid) storage.
Is there an alternative?
Possible solutions:
Start with enforcing versioning and later relax it to allow version=latest as tools (apps) become available.
Use JavaScript to control versions (however JS might change the content, see below).
Stick to pointers and versioning to avoid JS, as in IoT devices like cameras.
Browser / app level controls to switch between current and historical versions.
“By a) requiring that version always specified, b) providing option preferlatest flag, and c) implementing normal and historic browsing modes in user-agent, allow the web to be viewed as a dynamic ever-changing thing in the present, but also as global fixed snapshots in the past. This is powerful and has not existed before."
Calendar tab in browser/app to dial back through time, but to do that you would need to timestamp each version when published (See Timestamps below)
Perhaps a distinction could be made between “things that are used to build this page” vs “things that this page is linking to”.
Static vs dynamic sites
Safe can host static sites but dynamic sites are difficult because of versioning. Some static sites can behave like dynamic sites (e.g linking to version=latest), but they are not truly dynamic and this should be made clear to avoid confusion.
“You can link to documents such as a price list at latest version via normal NRS, just not load them directly into the page (as things stand)”
“Anything loaded as part of the page (images, javascript, css, audiofiles, video etc) has to be versioned or it will not load”
JavaScript
JavaScript can help with linked version choice but it may also promote risky behaviour.
A static page with JavaScript can show different content every time (eg Math.Random(), new content feed), but a page without JS cannot.
Mixing old and current materials on the same site may be tricky.
“JavaScript breaks all the efforts to enforce versions”.
Two lines of JavaScript to load an image.
Is using JavaScript to link to latest a useful halfway house or adding unnecessary complexity? How much load would it put on the network?
How to tell if linked content has been updated
Devs should be encouraged to version their content and users need a quick way of checking the currency of the linked content.
A three digit versioning scheme (x.y.z == ..) to provide an intuitive measure for the relative weight of an update
Sum total of all the versions linked to displayed. If something changes this number will too.
Tracking app.
Browsers / tools
Since NRS is app level, the controls around versioning will be in the app level too.
Have an indicator in browser when version is not the latest.
The option to scroll back version in the browser can be encouraged.
At the moment the browser just won’t load unversioned content (images/scripts/CSS)
But this doesn’t mean you cannot link to unversioned content or that (versioned) JavaScript cannot load unversioned content.
The option to scroll back version in the browser can be encouraged.
Backwards compatibility: Will browsers always maintain backwards compatibility over long periods of time?
Maybe insist on web standards like http headers to ensure compatibility.
Possible ‘developer mode’ in the browser which catches uncertain links which may cause a problem. And for a tool that automatically updates the version in links, etc.
Timestamps
Timestamps are a very human way of placing content in its temporal context, but difficult to achieve in a network that knows nothing of time. Some ideas:
Could timestamps be reliable if based on a section (elder/adult) or close group consensus?
NRS only resolves the site name. Updating AD objects does not store a timestamp either.
Would be a major change. Leave timestamps for application layers.
Perhaps could be managed off-network with third-party service, eg Opentimestamps.org, but maybe dangerous to depend on external services.
Time (if used) should enhance version, not supplant it.
Could time be factored into node age? If an elder is consistently out of time with the group they lose age.
Could be a tolerance on each time stamp which introduces an uncertainty that reflects what is fairly known?
Maybe the size of the Safe Network itself could be used instead of actual clock/calendar time.
"There already is a section timestamp similar to a Lamport clock [A simple algorithm used to determine the order of events in a distributed computer system]. But time is weird and does not work very well”.
Section chain network wide is a tree structure. So we can go back to any point in section time.
17 Likes
Hey, this is a great summary. Thanks for taking the time to write it up. A lot of valid stuff in this thread.
7 Likes
Thanks - it was getting a bit straggly so I thought it could do with condensing. Learned a lot in the process. So many clever people in this community.
11 Likes
The time stamping topic is really about decentralized oracles, a very interesting topic. That is, beyond providing reliable time, such nodes could provide other external data/facts such as demographic data, commodity prices, weather data, games scores, etc. If you look at the most popular decentralized oracle network right now, Chainlink, you realize that it’s actually centralized, among other issues. I think the Safe Network design lends itself to solving the oracle problem well in the future. It could potentially be something like specialist nodes that focus on oracle duty; so the oracle-to-be nodes go through the typical infant to adult progressions, changing sections randomly as their age increment, and serving data as currently understood. At the time when they can become elder, they are sent to a specialized oracle “section”. Now in an oracle “section”, the oracle node can perform oracle duties that it marked itself as wanting to perform when it joined the network as an infant and can no longer perform normal network duties to shield the network from any vagaries in oracle land. Furthermore, there may be additional rules in the oracle section like posting Safecoin collateral that would be slashed if the data (e.g., time, price, score) value they supply is off the average of their oracle section by a certain percentage, etc.
This is super crude. And there are many issues that’d need resolving (e.g., what address space do oracle sections occupy?) Another variation of the idea that would address this address space question would be to just have elders that have additional oracle duty on top of their normal duties; these oracle-elders would then be part of a secondary meta-like “section” along with other oracle-elders who are still part of their own normal sections.
Or maybe in the future elders just gain oracle function as well, which would be the simplest design-wise, but may require more from elders. They would be simply queried for external data instead of network data, and if a majority of them have it, then they provide it confidently, otherwise the client is warned that the value available is from a minority of elders or not available at all.
Yet another idea, clients could be polled for facts external to the network and the majority value taken as true. This may be open to sybil risks though (maybe client must provide Safecoin to vote and if their vote is within a certain average, they share in rewards otherwise they forfeit the Safecoin deposit)
Hopefully this is comprehensible and starts a discussion on decentralized oracles and how Safe N can help there in the future (well after network launch).
9 Likes
If you haven’t already seen it, I think you would find schellingcoin very interesting, based on the idea of Schelling Points. Also somewhat similar to Perpetual Auction Currency in a topic on this forum. But this is now getting very far from NRS!
As for timestamps, I reckon there’s a lot of utility in just having the client put one there if they think it would be useful. It’s better than nothing and most of the time there’s no incentive to give the incorrect timestamp. Of course user must beware, but I feel it’s easy to see bogeymen everywhere when in reality most of the time just asking or trusting is good enough. If we want to take someone to court then yeah this maybe isn’t good enough (but nothing would surprise me there); if we want to order a bunch of unrelated versions across domains then yeah just having the uploader add a timestamp is probably good enough. Kind of a dismissive approach I admit but I feel that keeping clock-time out of the base protocol is the right decision.
6 Likes
@JPL Super summary John, it’s helpful to have this all in one post. Quite a job!
@Bogard yes, good point about oracles, I think this could be an excellent addition to the duties of nodes [cough] and I’m wondering if it could be done entirely in the app later, without messing with the protocol, or at least with only minor tweaks to facilitate reward of oracles (similar to farming GETS).
There would need a way of declaring a task, like a market, and for nodes to put in their responses with proof of their age. A client app could utilise the ‘votes’ to determine the ‘answer’ to the task. Some questions here about how the oracles are rewarded and how this is paid for which might need some tweaking of the protocol, but maybe quite small enhancements would cover a lot of uses.
@mav I agree that voluntary metadata would probably do a good enough job at least short term. And probably forever for sites that link to independent content. It would be hard to get or create wrong times except for sites that do little or no external linking, and they’d probably be of less concern in this respect.
So no urgency IMO, but worth thinking about, though probably in another topic!
9 Likes
I think a topic itself and somehow pinned. These are nuggets of brilliance. I have become recently aware of the wall of test confusion, I do it myself. Where tons and tons of words are presented to humans they fuzz over it, but a clear and concise modular post where almost each paragraph/module conveys a nugget (intro, discussion & conclusion).
I am going to try from now to more clearly articulate nuggets and actively resist long rambles. @JPL is a past master at this and the post reflects the power in that way to communicating.
9 Likes
Yeah, that’s the first step. However, simple truth is that it is nearly always valuable to us humans and our dealings in the real even if it shouldn’t/couldn’t/wouldn’t be used by the network itself.
In my view it’s not about having the section provide a clock source or cyclical consistency for which we could correlate human clock time in realtime. That would be rather elegant and cool, but is non trivial nor necessary atm. The idea/concept about the network not using “time” in its operations and logic is a welcome design so no arguments there.
Instead, the time-stamping for pweb discussed above is about including a simple timestamp in the metadata to indicate what “humans” thought “their” notion of UTC time was when a PUT was used to mutate the network. The timestamp is for us and our logic, not the network.
For this to be useful it needs to be applied in a uniform manner. It doesn’t necessarily need to be applied at the chunk level or individual PUT (unless it’s easier that way), but it is critically important at the level of a reconstituted file as seen in one’s safe drive or in the browser.
5 Likes
Thanks for sharing this @mav. The mechanism described in Schellingcoin is indeed very reminiscent of your and Oetyng’s Perpetual Auction system. With a system like that/PAC and per @happybeing’s points above, oracles actually seem readily feasible on Safe as a layer on top of the base protocol. Very cool.
5 Likes
This script will register all TLD and popular domain names in nrs (bit of a Peter Todd style move I confess).
Could be expanded a lot, I only looked at USA, UK, China, India for domains, as well as global top 50. Looking through all countries will substantially expand the list. Probably the ordering could be optimized also, but I figure there’s so many other factors in this race that it wasn’t much point getting too focused on the specific ordering.
Took me about 6m to run on my baby-fleming network. Could be parallelized, but I’m not sure how much simultaneous load authd can take before it chokes. Anyway, here it is for future use.
# intended for use with safe_api v0.15.0
# assumes an account is already created, logged in, and funded
# replace with your own filescontainer
# be sure to include ?v=0 on the end
export FILESCONTAINER="safe://hnyynyq451ac1xj8dkndz5krjgopr9c3ywi4a6y1n3h816gnj5f7yn44q4bnc?v=0"
# sources for names are:
#
# https://data.iana.org/TLD/tlds-alpha-by-domain.txt
# https://www.alexa.com/topsites
# https://www.alexa.com/topsites/countries/*
# https://ahrefs.com/blog/most-visited-websites/
#
# reordered to have popular ones at the top
export NAMES="
com
org
net
gov
co
us
uk
cn
ru
io
google
youtube
tmall
baidu
qq
tencent
facebook
sohu
taobao
360
haosou
yahoo
jd
amazon
wikipedia
sina
weibo
zoom
reddit
live
netflix
xinuanet
microsoft
okezone
vk
office
instagram
alipay
csdn
myshopify
microsoftonline
bongacams
twitch
zhanqi
panda
naver
bing
ebay
aliexpress
tianya
china
apple
tribunnews
livejasmin
adobe
chaturbate
twitter
yelp
imdb
fandom
pinterest
tripadvisor
walmart
craigslist
linkedin
play
healthline
etsy
indeed
espn
webmd
fb
nytimes
cnn
merriam-webster
gamepedia
target
homedepot
quora
nih
rottentomatoes
quizlet
weather
mapquest
britannica
businessinsider
dictionary
zillow
mayoclinic
bestbuy
theguardian
msn
usatoday
medicalnewstoday
urbandictionary
usnews
foxnews
genius
allrecipes
spotify
glassdoor
forbes
cnet
irs
lowes
aol
steampowered
washingtonpost
usps
retailmenot
wiktionary
paypal
foodnetwork
hulu
cbssports
wayfair
ca
bleacherreport
macys
accuweather
xfinity
go
techradar
groupon
investopedia
yellowpages
steamcommunity
chase
wellsfargo
npr
apartments
roblox
huffpost
bankofamerica
bbb
expedia
wikihow
ign
wowhead
yy
huanqiu
17ok
sogou
1688
mama
jrj
so
babytree
soso
hao123
cnblogs
gome
6
billbili
163
rednet
eastday
iqiyi
aliyun
haosou
zhihu
51sole
51
cnnic
jiameng
cnzz
81
sonhoo
flipkart
hotstar
onlinesbi
indiatimes
hdfcbank
whatsapp
stackoverflow
primevideo
icicibank
zerodha
cricbuzz
manoramaonline
freepik
canva
adobe
thestartmagazine
udemy
naukri
moneycontrol
medium
wordpress
zoho
hindnow
amazonaws
grammarly
ndtv
indiamart
ilovepdf
speedtest
instructure
chase
dropbox
okta
imgur
salesforce
pornhub
bbc
ladbible
www
trustpilot
aparat
rightmove
dailymail
sportbible
ok
xhamster
duckduckgo
varzesh3
bt
virginmedia
sky
digikala
hotukdeals
argos
redd
it
ac
ad
ae
af
ag
ai
al
am
ao
aq
ar
as
at
au
aw
ax
az
ba
bb
bd
be
bf
bg
bh
bi
bj
bm
bn
bo
br
bs
bv
bw
by
bz
ca
cc
cd
cf
cg
ch
ci
ck
cl
cm
cr
cu
cv
cw
cx
cy
cz
de
dj
dk
dm
do
dz
ec
ee
eg
er
es
et
eu
fi
fj
fk
fm
fo
fr
ga
gb
gd
ge
gf
gg
gh
gi
gl
gm
gn
gp
gq
gr
gs
gt
gu
gw
gy
hk
hm
hn
hr
ht
hu
id
ie
il
im
in
iq
ir
is
je
jm
jo
jp
ke
kg
kh
ki
km
kn
kp
kr
kw
ky
kz
la
lb
lc
li
lk
lr
ls
lt
lu
lv
ly
ma
mc
md
me
mg
mh
mk
ml
mm
mn
mo
mp
mq
mr
ms
mt
mu
mv
mw
mx
my
mz
na
nc
ne
nf
ng
ni
nl
no
np
nr
nu
nz
om
pa
pe
pf
pg
ph
pk
pl
pm
pn
pr
ps
pt
pw
py
qa
re
ro
rs
rw
sa
sb
sc
sd
se
sg
sh
si
sj
sk
sl
sm
sn
so
sr
ss
st
su
sv
sx
sy
sz
tc
td
tf
tg
th
tj
tk
tl
tm
tn
to
tr
tt
tv
tw
tz
ua
ug
uk
uy
uz
va
vc
ve
vg
vi
vn
vu
wf
ws
ye
yt
za
zm
zw
aaa
aarp
abarth
abb
abbott
abbvie
abc
able
abogado
abudhabi
academy
accenture
accountant
accountants
aco
actor
adac
ads
adult
aeg
aero
aetna
afamilycompany
afl
africa
agakhan
agency
aig
airbus
airforce
airtel
akdn
alfaromeo
alibaba
alipay
allfinanz
allstate
ally
alsace
alstom
amazon
americanexpress
americanfamily
amex
amfam
amica
amsterdam
analytics
android
anquan
anz
aol
apartments
app
apple
aquarelle
arab
aramco
archi
army
arpa
art
arte
asda
asia
associates
athleta
attorney
auction
audi
audible
audio
auspost
author
auto
autos
avianca
aws
axa
azure
baby
baidu
banamex
bananarepublic
band
bank
bar
barcelona
barclaycard
barclays
barefoot
bargains
baseball
basketball
bauhaus
bayern
bbt
bbva
bcg
bcn
beats
beauty
beer
bentley
berlin
best
bestbuy
bet
bharti
bible
bid
bike
bing
bingo
bio
biz
black
blackfriday
blockbuster
blog
bloomberg
blue
bms
bmw
bnpparibas
boats
boehringer
bofa
bom
bond
boo
book
booking
bosch
bostik
boston
bot
boutique
box
bradesco
bridgestone
broadway
broker
brother
brussels
budapest
bugatti
build
builders
business
buy
buzz
bzh
cab
cafe
cal
call
calvinklein
cam
camera
camp
cancerresearch
canon
capetown
capital
capitalone
car
caravan
cards
care
career
careers
cars
casa
case
caseih
cash
casino
cat
catering
catholic
cba
cbn
cbre
cbs
ceb
center
ceo
cern
cfa
cfd
chanel
channel
charity
chat
cheap
chintai
christmas
chrome
church
cipriani
circle
cisco
citadel
citi
citic
city
cityeats
claims
cleaning
click
clinic
clinique
clothing
cloud
club
clubmed
coach
codes
coffee
college
cologne
comcast
commbank
community
company
compare
computer
comsec
condos
construction
consulting
contact
contractors
cooking
cookingchannel
cool
coop
corsica
country
coupon
coupons
courses
cpa
credit
creditcard
creditunion
cricket
crown
crs
cruise
cruises
csc
cuisinella
cymru
cyou
dabur
dad
dance
data
date
dating
datsun
day
dclk
dds
deal
dealer
deals
degree
delivery
dell
deloitte
delta
democrat
dental
dentist
desi
design
dev
dhl
diamonds
diet
digital
direct
directory
discount
discover
dish
diy
dnp
docs
doctor
dog
domains
dot
download
drive
dtv
dubai
duck
dunlop
dupont
durban
dvag
dvr
earth
eat
eco
edeka
edu
education
email
emerck
energy
engineer
engineering
enterprises
epson
equipment
ericsson
erni
esq
estate
etisalat
eurovision
eus
events
exchange
expert
exposed
express
extraspace
fage
fail
fairwinds
faith
family
fan
fans
farm
farmers
fashion
fast
fedex
feedback
ferrari
ferrero
fiat
fidelity
fido
film
final
finance
financial
fire
firestone
firmdale
fish
fishing
fit
fitness
flickr
flights
flir
florist
flowers
fly
foo
food
foodnetwork
football
ford
forex
forsale
forum
foundation
fox
free
fresenius
frl
frogans
frontdoor
frontier
ftr
fujitsu
fujixerox
fun
fund
furniture
futbol
fyi
gal
gallery
gallo
gallup
game
games
gap
garden
gay
gbiz
gdn
gea
gent
genting
george
ggee
gift
gifts
gives
giving
glade
glass
gle
global
globo
gmail
gmbh
gmo
gmx
godaddy
gold
goldpoint
golf
goo
goodyear
goog
google
gop
got
grainger
graphics
gratis
green
gripe
grocery
group
guardian
gucci
guge
guide
guitars
guru
hair
hamburg
hangout
haus
hbo
hdfc
hdfcbank
health
healthcare
help
helsinki
here
hermes
hgtv
hiphop
hisamitsu
hitachi
hiv
hkt
hockey
holdings
holiday
homedepot
homegoods
homes
homesense
honda
horse
hospital
host
hosting
hot
hoteles
hotels
hotmail
house
how
hsbc
hughes
hyatt
hyundai
ibm
icbc
ice
icu
ieee
ifm
ikano
imamat
imdb
immo
immobilien
inc
industries
infiniti
info
ing
ink
institute
insurance
insure
int
international
intuit
investments
ipiranga
irish
ismaili
ist
istanbul
itau
itv
iveco
jaguar
java
jcb
jcp
jeep
jetzt
jewelry
jio
jll
jmp
jnj
jobs
joburg
jot
joy
jpmorgan
jprs
juegos
juniper
kaufen
kddi
kerryhotels
kerrylogistics
kerryproperties
kfh
kia
kim
kinder
kindle
kitchen
kiwi
koeln
komatsu
kosher
kpmg
kpn
krd
kred
kuokgroup
kyoto
lacaixa
lamborghini
lamer
lancaster
lancia
land
landrover
lanxess
lasalle
lat
latino
latrobe
law
lawyer
lds
lease
leclerc
lefrak
legal
lego
lexus
lgbt
lidl
life
lifeinsurance
lifestyle
lighting
like
lilly
limited
limo
lincoln
linde
link
lipsy
live
living
lixil
llc
llp
loan
loans
locker
locus
loft
lol
london
lotte
lotto
love
lpl
lplfinancial
ltd
ltda
lundbeck
lupin
luxe
luxury
macys
madrid
maif
maison
makeup
man
management
mango
map
market
marketing
markets
marriott
marshalls
maserati
mattel
mba
mckinsey
med
media
meet
melbourne
meme
memorial
men
menu
merckmsd
miami
microsoft
mil
mini
mint
mit
mitsubishi
mlb
mls
mma
mobi
mobile
moda
moe
moi
mom
monash
money
monster
mormon
mortgage
moscow
moto
motorcycles
mov
movie
msd
mtn
mtr
museum
mutual
nab
nagoya
name
nationwide
natura
navy
nba
nec
netbank
netflix
network
neustar
new
newholland
news
next
nextdirect
nexus
nfl
ngo
nhk
nico
nike
nikon
ninja
nissan
nissay
nokia
northwesternmutual
norton
now
nowruz
nowtv
nra
nrw
ntt
nyc
obi
observer
off
office
okinawa
olayan
olayangroup
oldnavy
ollo
omega
one
ong
onl
online
onyourside
ooo
open
oracle
orange
organic
origins
osaka
otsuka
ott
ovh
page
panasonic
paris
pars
partners
parts
party
passagens
pay
pccw
pet
pfizer
pharmacy
phd
philips
phone
photo
photography
photos
physio
pics
pictet
pictures
pid
pin
ping
pink
pioneer
pizza
place
play
playstation
plumbing
plus
pnc
pohl
poker
politie
porn
post
pramerica
praxi
press
prime
pro
prod
productions
prof
progressive
promo
properties
property
protection
pru
prudential
pub
pwc
qpon
quebec
quest
qvc
racing
radio
raid
read
realestate
realtor
realty
recipes
red
redstone
redumbrella
rehab
reise
reisen
reit
reliance
ren
rent
rentals
repair
report
republican
rest
restaurant
review
reviews
rexroth
rich
richardli
ricoh
ril
rio
rip
rmit
rocher
rocks
rodeo
rogers
room
rsvp
rugby
ruhr
run
rwe
ryukyu
saarland
safe
safety
sakura
sale
salon
samsclub
samsung
sandvik
sandvikcoromant
sanofi
sap
sarl
sas
save
saxo
sbi
sbs
sca
scb
schaeffler
schmidt
scholarships
school
schule
schwarz
science
scjohnson
scot
search
seat
secure
security
seek
select
sener
services
ses
seven
sew
sex
sexy
sfr
shangrila
sharp
shaw
shell
shia
shiksha
shoes
shop
shopping
shouji
show
showtime
shriram
silk
sina
singles
site
ski
skin
sky
skype
sling
smart
smile
sncf
soccer
social
softbank
software
sohu
solar
solutions
song
sony
soy
space
sport
spot
spreadbetting
srl
stada
staples
star
statebank
statefarm
stc
stcgroup
stockholm
storage
store
stream
studio
study
style
sucks
supplies
supply
support
surf
surgery
suzuki
swatch
swiftcover
swiss
sydney
systems
tab
taipei
talk
taobao
target
tatamotors
tatar
tattoo
tax
taxi
tci
tdk
team
tech
technology
tel
temasek
tennis
teva
thd
theater
theatre
tiaa
tickets
tienda
tiffany
tips
tires
tirol
tjmaxx
tjx
tkmaxx
tmall
today
tokyo
tools
top
toray
toshiba
total
tours
town
toyota
toys
trade
trading
training
travel
travelchannel
travelers
travelersinsurance
trust
trv
tube
tui
tunes
tushu
tvs
ubank
ubs
unicom
university
uno
uol
ups
vacations
vana
vanguard
vegas
ventures
verisign
versicherung
vet
viajes
video
vig
viking
villas
vin
vip
virgin
visa
vision
viva
vivo
vlaanderen
vodka
volkswagen
volvo
vote
voting
voto
voyage
vuelos
wales
walmart
walter
wang
wanggou
watch
watches
weather
weatherchannel
webcam
weber
website
wed
wedding
weibo
weir
whoswho
wien
wiki
williamhill
win
windows
wine
winners
wme
wolterskluwer
woodside
work
works
world
wow
wtc
wtf
xbox
xerox
xfinity
xihuan
xin
xn--11b4c3d
xn--1ck2e1b
xn--1qqw23a
xn--2scrj9c
xn--30rr7y
xn--3bst00m
xn--3ds443g
xn--3e0b707e
xn--3hcrj9c
xn--3oq18vl8pn36a
xn--3pxu8k
xn--42c2d9a
xn--45br5cyl
xn--45brj9c
xn--45q11c
xn--4gbrim
xn--54b7fta0cc
xn--55qw42g
xn--55qx5d
xn--5su34j936bgsg
xn--5tzm5g
xn--6frz82g
xn--6qq986b3xl
xn--80adxhks
xn--80ao21a
xn--80aqecdr1a
xn--80asehdb
xn--80aswg
xn--8y0a063a
xn--90a3ac
xn--90ae
xn--90ais
xn--9dbq2a
xn--9et52u
xn--9krt00a
xn--b4w605ferd
xn--bck1b9a5dre4c
xn--c1avg
xn--c2br7g
xn--cck2b3b
xn--cckwcxetd
xn--cg4bki
xn--clchc0ea0b2g2a9gcd
xn--czr694b
xn--czrs0t
xn--czru2d
xn--d1acj3b
xn--d1alf
xn--e1a4c
xn--eckvdtc9d
xn--efvy88h
xn--fct429k
xn--fhbei
xn--fiq228c5hs
xn--fiq64b
xn--fiqs8s
xn--fiqz9s
xn--fjq720a
xn--flw351e
xn--fpcrj9c3d
xn--fzc2c9e2c
xn--fzys8d69uvgm
xn--g2xx48c
xn--gckr3f0f
xn--gecrj9c
xn--gk3at1e
xn--h2breg3eve
xn--h2brj9c
xn--h2brj9c8c
xn--hxt814e
xn--i1b6b1a6a2e
xn--imr513n
xn--io0a7i
xn--j1aef
xn--j1amh
xn--j6w193g
xn--jlq480n2rg
xn--jlq61u9w7b
xn--jvr189m
xn--kcrx77d1x4a
xn--kprw13d
xn--kpry57d
xn--kput3i
xn--l1acc
xn--lgbbat1ad8j
xn--mgb9awbf
xn--mgba3a3ejt
xn--mgba3a4f16a
xn--mgba7c0bbn0a
xn--mgbaakc7dvf
xn--mgbaam7a8h
xn--mgbab2bd
xn--mgbah1a3hjkrd
xn--mgbai9azgqp6j
xn--mgbayh7gpa
xn--mgbbh1a
xn--mgbbh1a71e
xn--mgbc0a9azcg
xn--mgbca7dzdo
xn--mgbcpq6gpa1a
xn--mgberp4a5d4ar
xn--mgbgu82a
xn--mgbi4ecexp
xn--mgbpl2fh
xn--mgbt3dhd
xn--mgbtx2b
xn--mgbx4cd0ab
xn--mix891f
xn--mk1bu44c
xn--mxtq1m
xn--ngbc5azd
xn--ngbe9e0a
xn--ngbrx
xn--node
xn--nqv7f
xn--nqv7fs00ema
xn--nyqy26a
xn--o3cw4h
xn--ogbpf8fl
xn--otu796d
xn--p1acf
xn--p1ai
xn--pgbs0dh
xn--pssy2u
xn--q7ce6a
xn--q9jyb4c
xn--qcka1pmc
xn--qxa6a
xn--qxam
xn--rhqv96g
xn--rovu88b
xn--rvc1e0am3e
xn--s9brj9c
xn--ses554g
xn--t60b56a
xn--tckwe
xn--tiq49xqyj
xn--unup4y
xn--vermgensberater-ctb
xn--vermgensberatung-pwb
xn--vhquv
xn--vuq861b
xn--w4r85el8fhu5dnra
xn--w4rs40l
xn--wgbh1c
xn--wgbl6a
xn--xhq521b
xn--xkc2al3hye2a
xn--xkc2dl3a5ee0h
xn--y9a3aq
xn--yfro4i67o
xn--ygbi2ammx
xn--zfr164b
xxx
xyz
yachts
yahoo
yamaxun
yandex
yodobashi
yoga
yokohama
you
youtube
yun
zappos
zara
zero
zip
zone
zuerich
"
for NAME in $NAMES
do
echo "Registering $NAME"
safe nrs create -l $FILESCONTAINER $NAME
done
12 Likes
I’ve never really used JavaScript, so this post might be entirely irrelevant as it’s based on my assumptions of how JS works.
Just be clear about what perpetual web means to me: I imagine being able to use the browser, jumping from link to link, with the knowledge that the version I’m looking at looks the same as when it was published and won’t ever change if I go back to the same version of the same site.
The problem
I think JS would be incompatible with a perpetual web if:
- It has access to any outside information
- It can load anything
1. Why outside information makes it incompatible with perpetual web: There was talk earlier in the thread about how the ability to generate random numbers might not be compatible with a perpetual web, and that means any information that could be used to generate random numbers is also incompatible.
Even being able to detect what links are clicked in JS could be a source of randomness as you could increment a variable each frame and there you have a number that can be used to generate a random number. Each time the user clicks a link a new timer can be started which can be combined with each other for increased randomness. Don’t know if this is actually possible with JS on the web, let me know if not.
2. Why the ability to load things makes it incompatible: If you can load things with JS, like an image for instance, that means you could write code like “try loading this file at version 100, if that doesn’t exist try loading version 99, etc. etc.”. This breaks the perpetuity. Again, I don’t know if this is actually possible, let me know if not.
Suggested solutions
A. Clearly distinguish in the browser between pages with JS and pages without. It could be some “warning” or icon or whatever that lets the user know that this safesite is not part of the perpetual web.
The drawback of this is that it still has the potential to break the perpetual web. Because if it turns out that 99% of sites use some form of JS, you wouldn’t be able to easily tell if a page is perpetual or not. Looking at the current web, I think there’s a high possibility that most safesites will use some JS if they can.
The result of this solution I think would likely be that the perpetual web wouldn’t really exist in the way I imagine it. There would be perpetual safesites, and some would link to one another, but since 99% of sites in this hypothetical future will probably use JS and thus are not necessarily perpetual, many perpetual sites would likely be cut off from one another with non-perpetual sites between. Thus there wouldn’t be a real web of perpetual sites, it would be more like a number of disconnected perpetual islands. “The perpetual islands”, or “the perpetual archipelago” might be a more fitting term for this.
B. Remove JavaScript’s ability to load external data. If the ability to load external things is removed, most downsides of JS when combined with a perpetual web are removed with it.
Maybe it’s ok to have a safesite that can do a bunch of programmy stuff, or random things or whatever. Because as long as it can’t load anything from the outside, it’s much harder to come up with ways to break the perpetual web with it, if it’s even possible.
However, with this functionality removed, JS and thus safesites would be much more limited.
C. Disable JavaScript entirely for the perpetual web. If you want to open a page with JS, that would be opened in another program because whatever is behind that link is not part of the perpetual web.
This separate program could be the same browser but with JavaScript enabled, maybe it treats the sites you visit more like individual apps, maybe they have their own windows etc. This makes it very clear what is and what is not a part of the perpetual web.
This is basically saying that if you’re using JS you’re not making a safesite, you’re making something else, you’re very welcome and encouraged to do so, but it’s not part of the perpetual web, it more lumped together with other standalone apps that interact with the Safe Network.
I imagine it treating JS kind of how Java or Python works, where you download the program and run it through your installed Java/Python interpreter.
This solution would also have the benefit of increasing the security of the browser a lot, without JS the attack surface is reduced dramatically.
Conclusion
I’ve always imagined the Safe Browser and the perpetual web to have JavaScript functionality, but after thinking about it I don’t think JavaScript is compatible with the perpetual web. Curious to read thoughts on this.
6 Likes
You’re correct in that the client code (JavaScript, wasm etc) will be able to break the perpetual web, and that even legitimate uses of this code will load differently at different visits even if the same version.
This isn’t much different than archiving current websites - whether the code is in JavaScript or on the server, the same version of a website can render differently each time you load it.
You could take a snapshot, store it away and load that. But is that representative, is it what you want or expect? The answer depends on the use you want to make of the archived data.
What to do? I’m not sure, but disabling JavaScript or other client side code is not going to work, because there is nowhere else to run code. It will work for simple static websites, but these will be a fraction of the Safe web, and for the most part they will be the least interesting or useful.
So yes, this is an issue. A useful first question is what do we want to happen?
Secondly, how can we make it easy for website and app builders to make this happen, and to have them on-board and want it to be so. At the moment, I think it could well be difficult to even build working websites using the current pWeb support, and I’ve been waiting for a testnet to explore this further. The last testnet had a first iteration of these features but didn’t last long enough to dig into them and what effect they had on different ways of building websites, in particular the frameworks which already exist and have no concept of URL versions.
I suspect without additional tooling only very simple static sites will just work to begin with. So to begin with you will probably get your no-JavaScript perpetual web after all! But those sites will be like the very first home-pages of Web 1.0.
So this is an important issue for the Safe pWeb and anyone wanting to build websites or apps on it. I don’t have the answers.
8 Likes
I’ve often wondered if we’d all be better off if javascript support was just stripped from safebrowser…
Does wasm need any javascript hooks?
Possibly not, but I’m not sure. The things I’m working on all involve JS to load and initialise the WASM. I’m not sure what you gain from disallowing JS if you have WASM.
Neither am I, that’s why I asked. It does expose a rust interface though… and better/cleaner encapsulation… maybe?
Is the pweb more important than flashy JS? I think so…