Add GUN protocol

[RangerMauve]

It'd be cool to flush out a gun-fetch protocol handler.

Main stuff that we'd need to figure out:

• What goes in the hostname as the 'origin'?
• How should sync work?
• Is there one global GUN or should we have named GUN instances per 'origin' kinda like names in hyper://
• The path portion of the URL should probably be split and used to invoke .get sequentially
• Should the username stuff go in the username portion? (pending on electron fix for this)

cc @amark

[amark]

🎉

Yes, I think domains should be deleted (use bootstrap peers or upcoming DHT) and have this as a global GUN.

GUN can store & sync other protocol URLs as well, but GUN itself should not be prefixed.

Yes, if you have the User system, that should be treated almost as the "domain".

[RangerMauve]

Interesting! Would you mind posting some GUN links that you could imagine loading in Agregore?

Something like gun:///path/to/key?

[lmangani]

can we help revive this topic? happy to help out

[RangerMauve]

@lmangani Yeah, that would be great!

Right now I'm slowly working on earthstar-fetch, but you're more than welcome to take on the gun-fetch implementation. 😁

Adding protocols typically looks like this:

• Figure out what URLs look like (good to talk to protocol maintainers if there isn't one already)
• Figure out what GET and POST would mean for those URLs
• Figure out how sync should work behind the scenes?
• Use the make-fetch library to implement a fetch interface for the URL scheme and it's verbs
• Add the fetch implementation into Agregore
• Show it off somewhere.

Would you be on to take on those steps? Or do you have ideas on other ways we could go about it?

[Dletta]

@RangerMauve gun does not follow a url schema, so get and post via fetch is likely not possible directly, but indirectly could be done via an http listener on a connected peer.

[RangerMauve]

@Dletta Would you be able to elaborate on what you mean regarding http listeners on a connected peer?

Instead of doing actual post and get (using HTTP server), I've been emulating the fetch() API that browsers provide. e.g. gemini-fetch which have most of the ground work in make-fetch so you can just define a bit of JS to actually handle URLs and HTTP method names / return a stream of data.

[Dletta]

@RangerMauve I mean we would need to use a middleware to allow http requests to be made into gun, as gun uses websocket mesh connections and does not expose an http interface.

[RangerMauve]

Oh yeah, 100% in agreement it would need to be some sort of wrapper over the gun API. I was thinking of implementing a fetch() like interface the way I've done for the other protocols in Agregore.

[resession]

this would be great, the only thing missing to me is gun. it would add a p2p db that everyone can use built-in to the browser.

discussion from gun matrix room

---

zedza: posted this on discord but also wanna post here, agregore web browser mixes p2p protocols, and they want to add gun protocol as well https://github.com/AgregoreWeb/agregore-browser/issues/81

amark (Mark Nadal): @ zedza:matrix.org nice, can you help with that? libensveto_twitter (libensveto)

zedza: @ amark (Mark Nadal) i would but i can't. my js/coding skills is beginner level. enough to create sites, but something like this would be beyond what i can do. i still created a bounty for it on bountysource. the main issue they are having is that agregore browser retrieves data with urls like fetch('some-p2p-url-here', options), but gun doesn't expose any urls like ipfs or hypercore/dat does

amark (Mark Nadal): @ zedza:matrix.org :thumbsup: . Hmm? That seems like a misunderstanding, GUN supports any text/string query, so for instance, you could (and various apps do do this already) do await gun.get('hashHere') or await gun.get('http://urlhere.com/foo') (now of course you need to save data to those keys, etc.)

libensveto_twitter (libensveto): if agregore:// can cache then its possible getting error Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document. at :2:1

amark (Mark Nadal): They block localstorage? That's sad. Check docs/RAD. That'll explain how to install indexedb instead. Tho maybe it doesn't allow that either? I'm sure it'll do normal filesystem stuff? Then can use the Nodejs code.

libensveto_twitter (libensveto): my bad agregore:// seems so be some weird hardcoded landing page hyper:// WILL allow for local storage but then again hyper is a key value store like gun in itself so thats not going to change the game, ideally we could do something like agregore://iris which would take you straight to iris

amark (Mark Nadal): Anyone on here (relay to discord too, tell everyone there to move off) good at reading flamegraphs?

zedza: amark (Mark Nadal): yep, i'm aware of what you're saying. they are using https://www.npmjs.com/package/make-fetch to "fetchify" retrieving data from p2p protocols. i think the main problem is turning '/some/route/to/hash/or/key' to .get('some').get('route').get('to').get('hash').get('or').get('key'), also the .on() and the once() and the chaining. think a small conversation with them would be good. i see a gun member is on their discord right now. good to see that way things can be straightened out. i let them know on their discord server to join here too if they want to talk and fix any misunderstanding. i am interested in this because adding gundb would give the browser a p2p db where you can potentially download a site from bittorrent and then use gundb as a database. all done with p2p. pretty nice thought

amark (Mark Nadal): 🎉🔥

---

[resession]

discussion from discord might be better to wait until gun finishes their dht update

didn't find anything on their github issues so pasting other links https://gun.eco/docs/DHT https://gun.eco/docs/AXE https://github.com/amark/gun/wiki/DHT

talking in gundb's matrix room to get more info, will paste here if there is any better link or page to follow the progress on their dht

[Dletta]

Their DHT may take a while, but newest version just came out

On Thu, Sep 2, 2021, 15:50 tedd pasta @.***> wrote:

discussion from discord might be better to wait until gun finishes their dht update

didn't find anything on their github issues so pasting other links https://gun.eco/docs/DHT https://gun.eco/docs/AXE https://github.com/amark/gun/wiki/DHT

talking in gundb's matrix room to get more info, will paste here if there is any better link or page to follow the progress on their dht

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AgregoreWeb/agregore-browser/issues/81#issuecomment-912046175, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLWWESMVGZ3365DWXU22JLT77PSLANCNFSM4UMYHGKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[resession]

Their DHT may take a while, but newest version just came out … On Thu, Sep 2, 2021, 15:50 tedd pasta @.***> wrote: discussion from discord might be better to wait until gun finishes their dht update didn't find anything on their github issues so pasting other links https://gun.eco/docs/DHT https://gun.eco/docs/AXE https://github.com/amark/gun/wiki/DHT talking in gundb's matrix room to get more info, will paste here if there is any better link or page to follow the progress on their dht — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLWWESMVGZ3365DWXU22JLT77PSLANCNFSM4UMYHGKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

yep, forgot that i asked gundb creator about this on discord.

---

zaaz: how does gundb utilize dht? i was looking at webtorrent and they use dht on their desktop/nodejs version. a good way to connect with other people without a signaling server at least for the desktop/nodejs apps.

marknadal: @ zaaz yeah new version with AXE tries to connect to local peer first, then "last" peers, then hardcoded/volunteer ones. DHT is upcoming. Trying to squeeze as much perf out first.

---

that was back in july, so gotta wait. still, i will paste more info if i get anything else from them. i still wanna make sure we are talking about the same concept of dht lol

[RangerMauve]

Thanks for the updates folks! 😁 While we wait for the DHT we might also want to think about the URLs and what sort of methods could work.

I think a good MVP would be to GET/PUT some data.

e.g. GET gun://SOUL_ID_HERE/property => CONTENT_HERE and PUTgun://SOUL_ID_HERE/property "Hello World" => update the field`

[resession]

chaining would have to be taken care of, if someone wants to .get('key1').get('key2').get('key3'). maybe GET gun://SOUL_ID_HERE/property1/property2/property3 -> get all properties by splitting the '/' -> then turn it into .get('property1').get('property2').get('property3')

also, we would have to think about the streaming methods like .on(), whether it should be supported or not. if you want to support that then we would have to figure out how to handle that since methods like .on() sends a stream when the data changes.

[RangerMauve]

Splitting paths into .get() chains is a great idea. We should definitely have that.

Streaming methods like .on could be done via EventSource. Essentially, if you GET with the Accept HTTP header set to text/event-stream, you can get back a series of events that are easy to listen on in JavaScript.

I'm not sure if there are limitations on how many you can listen to at a time though or how many of these streams people use in apps typically.

[resession]

https://github.com/resession/gun-fetch

gundb focuses on get and put, currently i am using GET, DELETE, and POST.

GET gun://user > gets user info with public key gun://path /some/path/to/user/data > gets some data about a user gun://get /some/data > general route to get any data

POST gun://user > create a user, different paths will do different things gun://create /some/route/to/put/data > create data, puts body on the given route

DELETE gun://user > delete a user, different paths will do different things gun://delete /some/route/to/delete/data > delete data, deletes data on the given route

just a test run to see if i can get the ball rolling i am using the gun/lib/path.js module to chain the url to .get(), gun/lib/path.js is deprecated though, think i found another way

[RangerMauve]

Sweet. Nice to see progress on this stuff!

One thing I worry about is having what looks like methods within the hostname portion of the URL.

Ideally URLs should look like gun://SOME_AUTHORITY_HERE/path/to/resource combined with methods to GET/POST/DELETE from the path with different content-types. Additional metadata is usually placed inside HTTP headers.

That way, the URLs play nice with the browser's origin isolation, so a given soul could be considered like it's own website. Having keys like user and create in the SOME_AUTHORITY_HERE portion makes the URLs kind of non-standard and makes it harder to take advantage of certain browser features and URL parsers.

As I understand, both user and regular nodes in the graph use souls to uniquely identify them, similar to CIDs in IPFS. How would you feel about using those in the authority portion of the URL and using HTTP methods for stuff like create.

E.g.

fetch('gun://~@userAliasHere/path/to/node', {
  method: 'PUT',
  body: JSON.stringify({
    hello: 'world'
  })
})

// Same as
gun.get('~@userAliasHere').once((user) => user
  .get('path')
  .get('to')
  .get('node')
  .put({hello: 'world'})
)

// Or

const response = await fetch('gun://#soulIDHere/some/path')
const data = await response.json()

// Same as
gun.get({
  _: {'#': 'soulIDHere'}
}).get('some').get('path')
.once((data) => whatever)

Does that setup make sense? It might be a bit more effort on the implementation side, but it could lead to more interoperability between protocols and some cleaner URLs that better map to data rather than function calls.

[resession]

Sweet. Nice to see progress on this stuff!

One thing I worry about is having what looks like methods within the hostname portion of the URL.

Ideally URLs should look like gun://SOME_AUTHORITY_HERE/path/to/resource combined with methods to GET/POST/DELETE from the path with different content-types. Additional metadata is usually placed inside HTTP headers.

That way, the URLs play nice with the browser's origin isolation, so a given soul could be considered like it's own website. Having keys like user and create in the SOME_AUTHORITY_HERE portion makes the URLs kind of non-standard and makes it harder to take advantage of certain browser features and URL parsers.

As I understand, both user and regular nodes in the graph use souls to uniquely identify them, similar to CIDs in IPFS. How would you feel about using those in the authority portion of the URL and using HTTP methods for stuff like create.

E.g.

fetch('gun://~@userAliasHere/path/to/node', {
  method: 'PUT',
  body: JSON.stringify({
    hello: 'world'
  })
})

// Same as
gun.get('~@userAliasHere').once((user) => user
  .get('path')
  .get('to')
  .get('node')
  .put({hello: 'world'})
)

// Or

const response = await fetch('gun://#soulIDHere/some/path')
const data = await response.json()

// Same as
gun.get({
  _: {'#': 'soulIDHere'}
}).get('some').get('path')
.once((data) => whatever)

Does that setup make sense? It might be a bit more effort on the implementation side, but it could lead to more interoperability between protocols and some cleaner URLs that better map to data rather than function calls.

i'm planning to work on it and change things next week. nice ideas, what you said made sense. the first thing i was gonna think about is the uri/url scheme. what i have right now was just blind coding without ideas, testing stuff. so what is everyone's thought on gun://soulIDHere compared to gun://~@userHere? any preferences? i am leaning on the side of gun://soulID, easy and simple.

[resession]

made some updates on the gun-fetch package. now it makes use of headers, an x-gun-fig and x-gun-func header. also now it uses GET, PUT and DELETE. takes the headers and makes a query out of it, and then based of the http method used, it gives a response.

[RangerMauve]

Thank you for the progress update! This is looking a lot closer to something REST-ful.

Is there a way that the headers could be avoided? The way it works right now would make it hard to share URLs with folks. e.g. gun://something/whatever could refer to any of a bunch of options.

One thing that might be useful is to determine the type of "thing" that is is by using special characters in the HOSTNAME portion of the URL. e.g. how User UUIDs start with a ~.

Regarding all the functions, is there a way to determine what makes the most sense for a given URL? Like, for PUT you currently have .put, .set, user.create, and user.auth. Like, between .put and .set could one of these instead use the PATCH method? And regarding user creation, would it make sense to use something else in the URL to distringuish a new user from an existing user? (like using an existing public key to say we're authenticating).

As well, it'd be useful if the README (or a test.js file) had some examples of what URLs and HTTP options would look like for each feature so we can see how it'd look from an actual users perspective. for example how js-ipfs-fetch has a README and tests.

But yeah, I think we're close to having URLs that follow existing precedents from other protocols, and I'm confident that once we figure it out it'll be easy to mix with other protocols and web things in general.

[RangerMauve]

Thank you for your patience in working through this stuff BTW! It's all very cutting edge and experimental. :P

[RangerMauve]

Another thought I'm having. What if we think of an initial spec that doesn't bother with supporting gun.user to start, and focus more on the data itself. The user stuff is also complicated because all of Agregore would be sharing a single gun-fetch instance, so all websites would need to reuse a user (I think). Maybe after we have the raw data figured out we could have something that automatically sets up a user from within the Agregore protocol handler code?

[Dletta]

.set doesn't need it's own route, as it really is just a shorthand for .get(randomName).put(object/string)

On Thu, Oct 21, 2021, 13:33 RangerMauve @.***> wrote:

Another thought I'm having. What if we think of an initial spec that doesn't bother with supporting gun.user to start, and focus more on the data itself. The user stuff is also complicated because all of Agregore would be sharing a single gun-fetch instance, so all websites would need to reuse a user (I think). Maybe after we have the raw data figured out we could have something that automatically sets up a user from within the Agregore protocol handler code?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AgregoreWeb/agregore-browser/issues/81#issuecomment-948895748, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLWWEWMFA4RJH3VNS2CLN3UIBMGXANCNFSM4UMYHGKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[resession]

.set doesn't need it's own route, as it really is just a shorthand for .get(randomName).put(object/string) … On Thu, Oct 21, 2021, 13:33 RangerMauve @.***> wrote: Another thought I'm having. What if we think of an initial spec that doesn't bother with supporting gun.user to start, and focus more on the data itself. The user stuff is also complicated because all of Agregore would be sharing a single gun-fetch instance, so all websites would need to reuse a user (I think). Maybe after we have the raw data figured out we could have something that automatically sets up a user from within the Agregore protocol handler code? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLWWEWMFA4RJH3VNS2CLN3UIBMGXANCNFSM4UMYHGKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Did some research on this. On stackoveflow @amark have said .set() is better for an array like interaction. Safely adding things to an unordered list. I didn't read it fully but it made me think .set() might have some other uses depending on the situation.

[resession]

made updates, seems more clean to me update 1: no more headers, instead special characters does the work headers would have done, here is what a get request with a path query would look like fetch('gun://_some/thing', {method: 'GET'})

update 2: add an OPTIONS method for different types of queries such as a NOT query

update 3: gun-fetch will have only one user that way the uri scheme makes sense, when gun-fetch starts a single user is created and authenticated, you can interact with the user by doing this fetch('gun://$some/thing', {method: 'PUT', body: 'some text'}) here $ would be the user(or gun.user()), let's say you want to see the full user node, then you can use the option request or the user such as fetch('.$', {method: 'OPTIONS'}) this will give you the entire user node, . is the options character and $ is the user character, nothing else is needed as part of the hostname

planning to work on the readme.md soon

------------- edit -------------

most request now should be running smooth. the only thing that is a problem is stuff with users. so i got an idea, how about use the special characters for that? we have the OPTIONS method/character which is . . so let's say we make a user character be '$', so '.$someAlias' is someone wanting to work with user 'someAlias'. '.$+someAlias' would be create the user and '.$-someAlias' would be delete the user. but 3 special characters might be too much, but its a lot more simpler than headers and doesn't seem messy.

[resession]

so there are 3 options

1. ability to work with unlimited users
2. have only one signle user
3. have no user system at all

just finished some changes i have made. so now with the usage of special characters, we can work with unlimited users. the rest of gun-fetch looks good. if working with unlimited users or single user is too much for right now, then we can put it to the side. but from what i have right now, it looks workable to me. so here are some examples. fetch('gun://.$&someAliasHereToCreate', {method: 'OPTIONS', body: 'somePassword'}) . is options, $ is user, & is the create user option, so using the options character we create a new user fetch('gun://.$+someAliasToLogin', {method: 'OPTIONS', body: 'somePassword'}) same thing as before but this time + is the login option

[resession]

worked on the readme.md and made some updates again. making users should be really easy now. and everything else seems smooth as well.

so gun-fetch now assumes that if you use >>> fetch('gun://someTextWithoutSpecialCharacter') <<< this will be a user interaction. anything with a special character will mean that you want to make a query, a non-user query. as it is right now, everything seems balanced. each HTTP method only has two possible outcomes, a user query or a non-user query.

readme.md will be updated to explain more of this

[resession]

right now, i will test every route and make sure it is working without errors and bugs. if everything works, then i think this is good. all the things that was talked about here has been implemented. last time, methods such as PUT was handling 4 functions, that is gone. each HTTP method only has two possible functions/response, user or a non-user response. the user interaction had the most issues, now it is really easy, probably the easiest part of gun-fetch now(and not a single user, you can have unlimited user). and we got rid of headers, replaced it with special characters which made things much more smoother.

there is just one more thing i can think of that might make it even better. which i will work on and test. but that's the update for now

[resession]

made those updates that i was talking about. so here is how the url works now. gun://_something | special character - url | this would mean a query gun://something | no special character - just url | this would mean doing crud stuff with a logged in user gun://something. | url - then a dot(.) at the end | this would mean creating or logging in a user, in this case, "something" would be the alias and the body will have the password

so overall, if a url has no special character, then you would be doing crud things with a user that is logged in if there is a special character in the front, then you are making a query if there is a dot(.) in the end of the url and no special character in the front, then you are creating or logging in a user

[resession]

made an update, and this change will be a final change.

i realized with gundb, there is two kinds of queries. path and user. pubkey, alias, these are something to do with users. the other main query is the regular path.

so now anything with a special character in the hostname, is a user query. any hostname without a special character, will be a path query.

so without special character/path gun://some/thing - gun.get('some').get('thing')

and with special character/user gun://_pubkey - gun.user('pubkey') gun://*alias - gun.get('~@alias') gun://~useraliasthatisloggedin - gun.user().auth()

so this way does two things. first it achieves the original goal, which is have an easy uri scheme to get resources from gundb, using the soul/path query makes it easy just gun://your/query/here

and users being a big part of gundb, we also support user interactions, since the user is more complex, we use special characters to make the users part a lot easier

so there you go, i think this is a good base and i will stick to this base

[resession]

updated the readme, i will be active on the https://github.com/resession/gun-fetch when it comes to gun-fetch, if you need anything for gun-fetch, let me know there in the gun-fetch repo

[RangerMauve]

Hey! Sorry for not doing up more in depth review sooner, I'm still going to be super busy until Monday or tuesday. Would you be able to double check that the URLs all parts correctly inside electron? If you check out the protocols/index.js file inside agricor you should be able to see how to add a protocol to it. From there it'll be useful to register gun as a standard schema and then tests all of the URLs in your readme using new URL(”gun://whatever‘) to make sure that none of the special characters are being eaten up by Chrome's url parser

[resession]

Hey! Sorry for not doing up more in depth review sooner, I'm still going to be super busy until Monday or tuesday. Would you be able to double check that the URLs all parts correctly inside electron? If you check out the protocols/index.js file inside agricor you should be able to see how to add a protocol to it. From there it'll be useful to register gun as a standard schema and then tests all of the URLs in your readme using new URL(”gun://whatever‘) to make sure that none of the special characters are being eaten up by Chrome's url parser

cloned agregore and tried it. chrome/chromium was messing up the special characters. i am now decoding the hostname for now. works without errors now. since gun-fetch is decoding the hostname, i changed some of the special character, looks nicer. but all in all, the special characters works as they should.

why decode the special characters? there are 3 characters that are fine with chrome's url parser. _, ., -. we need 4 open special characters, so we still gotta decode the hostname,

[resession]

found an error. chrome or agregore is automatically turning everything into lowercase. we need to keep the letters as they are, the pubkey will have uppercase letters, and if they are converted to lowercase, then gundb will not be able to retrieve the user, basically, gun.user(pubkeyHere) will not work. gun-fetch by itself works with uppercases, i tested it. so its happening with either chrome, agregore, maybe one of the dependencies, or maybe an option that is turned on.

edit--------- wow my mistake, casing of the hostname never mattered on anything i worked on. but looks like the browser will turn it to lowercase regardless of what we do. maybe electron has an option to keep the uppercase. i will wait for your reply on this to see if electron has that option.

edit----------- don't think electron will have any option to force uppercase, browsers will always change it to lowercase because hostname is case-insensitive. a header can be used to solve this though. but you were trying to not use headers. so any ideas? don't think there is a url/hostname level solution for this. header is the best and easiest solution i can think of. send the pubkey/alias for user lookups with the HOST header.

edit-------- while the browser will convert the hostname to lowercase, the browser does not convert the path. so another potential solution is having the pubkey and alias in the path, then for user interaction, the entire hostname can be just a single special character. so for example, gun://_/pubkeyHere or gun://*/somePersonsAliasHere, my online reading about this subject says, there is nothing against doing this. hostnames can be a single character. but at the same time, while its doable, single character hsotname isn't the norm.

[RangerMauve]

Sadly the hostname part of URLs is case insensitive, so if you need to encode something you'd need to use a slightly different system. What encoding is being used right now? Can we use hex?

[resession]

Sadly the hostname part of URLs is case insensitive, so if you need to encode something you'd need to use a slightly different system. What encoding is being used right now? Can we use hex?

chrome is applying percent encoding on symbols, so i am using decodeURIComponent to turn it back into a regular symbol.

[resession]

what are your thoughts on the hostname casing issue, you like the gun://singleSpecialCharacterHere/pubkey, or do you like the HOST header idea, or do you have another solution/idea?

[RangerMauve]

I think they're requires a lot more attention that I can't give today or tomorrow. 😅 Sorry!

[resession]

I think they're requires a lot more attention that I can't give today or tomorrow. 😅 Sorry!

no prob, i'll check back on this mid-this coming week and then go from there.

[Dletta]

Just s thought, maybe b64 encode url strings?

On Sat, Oct 30, 2021, 18:08 tedd pasta @.***> wrote:

I think they're requires a lot more attention that I can't give today or tomorrow. 😅 Sorry!

no prob, i'll check back on this mid-this coming week and then go from there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AgregoreWeb/agregore-browser/issues/81#issuecomment-955605985, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLWWEXIRLQU2ALLCC572ULUJR3HXANCNFSM4UMYHGKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[resession]

b64 encode url strings

thanks for the suggestion, i checked it. i can't see it working. the browser will automatically lowercase the hostname, so if we encode the hostname, the encoding itself will be lowercased. and i checked base64, seems like it is case-sensitive, if we change the casing of the encoding, then it will not work.

[Dletta]

Ah, that makes sense. I couldn't remember whether it was case-sensitive

On Sat, Oct 30, 2021, 18:48 tedd pasta @.***> wrote:

b64 encode url strings

i will checked it. can't see it working. the browser will automatically lowercase the hostname, so if we encode the hostname, the encoding itself will be lowercased. and i checked base64, seems like it is case-sensitive, if we change the casing of the encoding, then it will not work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AgregoreWeb/agregore-browser/issues/81#issuecomment-955608896, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLWWETJHKQBOIW7EVJFF7DUJR74TANCNFSM4UMYHGKA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[resession]

I added the special character "."

fetch('gun://.someHexAsHostname') works, temporary solution though most likely

[resession]

i made a test folder that holds the two different ways of solving this hostname lowercasing issue.

https://github.com/resession/gun-fetch/blob/main/test/index%20HEX%20HOSTNAME.js https://github.com/resession/gun-fetch/blob/main/test/index%20SINGLE%20CHARACTER%20HOSTNAME.js

so instead of: gun://specialCharacterWithSoul - gun://*someAlias

it would be the following: gun://specialCharacterBytIself/soulHere - gun://*/someAlias

using a single special character as the hostname is a lot easier, we don't have to worry about casing since the browser only lowercases the hostname, path is untouched, from my reading there is nothing against single character hostnames. though it might not be the most aesthetically pleasing. works none the less.

when you get some time, let me know your thoughts about this, i tried the single special character hostname idea on agregore, it works

[RangerMauve]

Hmm. Having the special character in the hostname portion would break same-origin stuff. Does that matter for stuff like usernames? If we omit the special characters for regular blocks it might be nice for being able to do stuff like publishing a website under a given node. (is that possible?)

Using an encoding that isn't case sensitive would probably be good for forwards compatibility though. IPFS has recently migrated to that (I think using base36 and base32).

[RangerMauve]

Hmmm. Is there a way we could combine the alias * and pubkey _ syntax together? Like, could they both be ~ and then try to detect if it's an existing hex public key, else treat it as an alias?

As well, would it make sense to treat the / path for users as something special? e.g. if you POST to gun://~someAlias, it'll create the user ~@someAlias using params from the body.

e.g.

gun://~whatever/ == gun.user('~@whatever') or `gun.user(Buffer.from('whatever', 'hex')) (if it's 32 hex bytes)

Thinking about special characters in the hostname paramter, I think if we treat ~ as a special character for users, maybe the literal hostname ~ could refer to just the current user.

e.g.

gun://~someAlias/whatever/ => particular user
gun://~/whatever => currently logged in user

PUT `gun://~/` {pulicKey, privateKey => log in as this user

Regarding OPTIONS, that method is used everywhere that GET is by browsers and should return the same response but without the body set. I think if you want a NOT operation, it might be good to put it into the querystring. E.g. gun://something?not

[RangerMauve]

Main thing I'm thinking is that it'd be good to keep hostnames as close as possible to being a consistent origin, as well to have the HTTP methods align with what browsers would usually use them for.

Thank you again for all your patience in figuring this out. 😅 Gun is definitely turning out to be one of the more complex protocols to integrate thanks to the user auth, but I think whatever we figure out here could also be useful for future protocols.

[resession]

here is the error

i originally planned to use ~, but i keep getting an error. did some digging, and i think chrome/electron is not going to like ~, so gotta change it to another symbol. i'll make changes and update when i'm done.

[resession]

made some changes

_ now is used for both alias and pubkey

. is used for users and user auth .somealias means somealias is logged in, means you want to crud . by itself means you want user auth interaction(login, logout, register, destroy), username and password will be part of the body as properties of the body One thing to note is the username must be lowercase

no special character means you want a regular property lookup

a querystring/param with a get request gun://some/thing?not=anything, that not would return a NOT query, if you want a regular query though just don't put the 'not' querystring/param

still have to test it though, which i will do tomorrow

[resession]

tested the changes on agregore. everything works, all errors that were encountered has now been fixed. if there are any errors that people encounter, please make an issue on the gun-fetch repo. check it out @RangerMauve and let me know your thoughts