-
Notifications
You must be signed in to change notification settings - Fork 1
Add some comments as a review. #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
(I couldn't add comments in GH review to the lines without changes... so I left them inlined. Internally it's probably just a git patch with a diff) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mariha Thank you for the detailed & thoughtful comments and suggestions!
I haven't finished the review fully.
For starters, what do you think @mariha if i separately merge the parts which are related (typos & formatting, TOC, OHN intro, content changes & change in meaning)? It could help simplify further discussion to points that may require more discussion.
Also, for the points that i may not like for any reason, it may work great to fork/copy this to OHN, and show the changes there.
WDYT? :)
| In a series of articles we document how we build a distributed hospitality exchange over [Solid](https://solidproject.org). | ||
|
|
||
| [Start here](intro.md) | ||
| [comment]: <> (Who are we? Would be nice to write that it was you together with OHN project/team or you as part of it) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely!
| ### 1. Crawl a network of friends of a friends | ||
|
|
||
| Well, people can look at their friends, and friends of friends, and friends of friends of friends, and so on, and see if somebody offers a place to stay; and where it is. | ||
| Well, people can ask (look at the profile of) their friends, and friends of friends, and friends of friends of friends, and so on, and see if somebody offers a place to stay; and where it is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
people can look at the profile of their friends or people can look at the data of their friends sounds good to me. To me ask represents act of asking them, and getting answers, which they don't do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it would be nice to make it a bit more general in a way that in real/physical/offline world people would ask their friends and this is what the program "models" but I don't insist.
| - Offers have to be public. Currently, Solid doesn't have any mechanism to give permissions to friends of friends of friends of friends, and nobody else. (We could make a crawler that for each user collects these "foafoafoafs" to a single group, traversing the graph to certain depth, and give permissions to that group (or rather request members of that group to give permission to read their data).) | ||
| - We don't have any notion of a Community (e.g. cyclists, hitchhikers, ...) - like [different](https://welcometomygarden.org/) [hospex](https://www.bewelcome.org/) [communities](https://www.facebook.com/groups/hostasister/), or different [Trustroots Circles](https://www.trustroots.org/circles) (could be done with "tags" stored in a profile) | ||
| - Search by location would require prior fetch and scan of a whole network of foafoafoafs, that would take waaaaaaay to long to be usable (scalability and app responsiveness issues) unless we cache that data locally but then it can get stale, needs refreshments, ... gets a bit complicated. A cache could be structured as a geospecial index though, specifically created for each user from their own network. That might be not that bad idea, actually. | ||
| - There is no common space to broadcast messages (invitations to stay or requests to be hosted), unless we had a wall of messages from foafoafoafs, stored locally and refreshed similarly as messages in SSB? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this already assumes an architecture: That we don't send messages to others directly, but put them on a wall for others to discover?
Or is this about messages that are public by their nature? Like request for an area (not a person)?
I think this, also with comparing to SSB, makes it a bit complicated. I'd keep it for future reference, but prefer not to include for now, for simplicity and clarity.
Definitely makes sense to include when we'll start discussing messaging architecture (future)
| 1. Everybody in the internet can see the list of hospitality exchange members | ||
| 2. Group is private, but the people's hospex data are public. ([this doesn't work if the group is hosted on CSS](https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1442)) | ||
|
|
||
| [comment]: <> (What if we had a functional webId for each hospex community, and we created a public Solid Group that included them and authorized only members of this group to see people's hospex data? Each community would have a separate app/webpage, with their own webId. Only app would be authorized to access hospex data of members of the community it serves. The members directly or other apps/communities would not be authorized to read that data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, let's discuss this further!
I don't fully grasp: so all the hospex data would get proxied through the community? E.g. community would fetch the data (because it has the permission to read) and then it would pass the data further to the end user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like a lot the idea that an organization could have its own id. Possibly https://id.sleepy.bike ... :) There was a piece about webIds at the July (2022) Solid World... (the whole talk of that presenter starts at 38m24s)
How we could and wanted to use this id, that's for further discussion - i haven't properly thought through the possibilities....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't fully grasp: so all the hospex data would get proxied through the community? E.g. community would fetch the data (because it has the permission to read) and then it would pass the data further to the end user?
yup, exactly. Basically, we'd add a layer of indirection into who is authorized to access the data. A user would not access it directly but rather the app would do it for them. This gives also more flexibility to what the app does with the data, could for example display a map with hosts before a person is logged in.
I'll try to watch the video tomorrow morning.
| I don't care for the inception ideas. I don't care for authority in Solid. I don't care for your new Specification. I want it to work. | ||
|
|
||
| [comment]: <> (I don't care for your new Specification) | ||
| [comment]: <> (it's unclear to me who is "your" here. Maybe adding a link under "Specialization" will help, or changing "your" to somthing more specific?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. So apparently this is not written clearly.
I speak about Specs (i.e. RFCs) that academic-minded people like to produce, before having the proof of concept.
Example of spec-focused vs lets-make-it-work-focused spec is XML vs JSON as data exchange format (not in our context, though), or as Aaron Swartz wrote in Intro to Programmable web:
With them has come academic research and government grants and corporate R&D and the whole apparatus of people and institutions that scream “pipedream.” And instead of spending time building things, they’ve convinced people interested in these ideas that the first thing we need to do is write standards. (To engineers, this is absurd from the start—standards are things you write after you’ve got something working, not before!)
Perhaps we could add link to the efforts of solid interoperability panel... :) Not sure if it's offensive to point fingers, though...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yea. I like to say that for me standards should emerge from many tested solutions to a problem as the ones that get used and adapted most often and hence they become standard(s), rather than something being enforced as a standard. Clearly top-down vs bottom-up approach to problem solving.
Perhaps we could add link to the efforts of solid interoperability panel... :) Not sure if it's offensive to point fingers, though...
I think you could add a link.
|
|
||
| One well explored, and popular use case is Hospitality Exchange. It's pretty clear what the system should do. | ||
|
|
||
| [comment]: <> (would be great if you mentioned somewhere here, here-here or elswhere on this page, how your collaboration with me or/and OHN started, what OHN is about and how it fits together with Your agenda. Maybe also a few words about sleepy.bike, who is it for and where it comes from? I'll be happy to discuss or draft parts of this if it was helpful.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great. Definitely, let's include.
If you have some text, or could draft some, that could be helpful. We could even make a shorter comment here and link it to a longer text with its own separate page. :)
mariha
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the answers!
In general, anything you think will make the process of applying changes easier works great to me. I am sorry for making the comments in files instead of GH review but there were too many places where I wanted to comment something without making a change.
I am working a bit in between girls' interruptions so may be more chaotic than I wish to be at a times, hope it won't get too annoying for you.
| ### 1. Crawl a network of friends of a friends | ||
|
|
||
| Well, people can look at their friends, and friends of friends, and friends of friends of friends, and so on, and see if somebody offers a place to stay; and where it is. | ||
| Well, people can ask (look at the profile of) their friends, and friends of friends, and friends of friends of friends, and so on, and see if somebody offers a place to stay; and where it is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it would be nice to make it a bit more general in a way that in real/physical/offline world people would ask their friends and this is what the program "models" but I don't insist.
| 1. Everybody in the internet can see the list of hospitality exchange members | ||
| 2. Group is private, but the people's hospex data are public. ([this doesn't work if the group is hosted on CSS](https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1442)) | ||
|
|
||
| [comment]: <> (What if we had a functional webId for each hospex community, and we created a public Solid Group that included them and authorized only members of this group to see people's hospex data? Each community would have a separate app/webpage, with their own webId. Only app would be authorized to access hospex data of members of the community it serves. The members directly or other apps/communities would not be authorized to read that data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't fully grasp: so all the hospex data would get proxied through the community? E.g. community would fetch the data (because it has the permission to read) and then it would pass the data further to the end user?
yup, exactly. Basically, we'd add a layer of indirection into who is authorized to access the data. A user would not access it directly but rather the app would do it for them. This gives also more flexibility to what the app does with the data, could for example display a map with hosts before a person is logged in.
I'll try to watch the video tomorrow morning.
| I don't care for the inception ideas. I don't care for authority in Solid. I don't care for your new Specification. I want it to work. | ||
|
|
||
| [comment]: <> (I don't care for your new Specification) | ||
| [comment]: <> (it's unclear to me who is "your" here. Maybe adding a link under "Specialization" will help, or changing "your" to somthing more specific?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yea. I like to say that for me standards should emerge from many tested solutions to a problem as the ones that get used and adapted most often and hence they become standard(s), rather than something being enforced as a standard. Clearly top-down vs bottom-up approach to problem solving.
Perhaps we could add link to the efforts of solid interoperability panel... :) Not sure if it's offensive to point fingers, though...
I think you could add a link.
They were added as comments to a GH review instead.
This reverts commit 472ae11.
|
added further changes in 5f6aaf0 and removed them from here |
#1 Co-authored-by: mrkvon <mrkvon@protonmail.com>
|
Finally, we've added content changes based on this review in ac6e2fb |
#1 Co-authored-by: mrkvon <mrkvon@protonmail.com>
c0a1981 to
e25c2af
Compare
Take or ignore whatever you think is worth it.
I'll move the comments inlined in the files to GH comments in a moment...