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.
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?
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”.
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
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 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".
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?
Start with enforcing versioning and later relax it to allow version=latest as tools (apps) become available.
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)”
Mixing old and current materials on the same site may be tricky.
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.
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)
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 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.
Hey, this is a great summary. Thanks for taking the time to write it up. A lot of valid stuff in this thread.
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.
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).
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.
@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!
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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…