Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 04:47
    bblfish edited #248
  • Oct 16 05:56

    bblfish on draft-minutes

    number proposal (compare)

  • Oct 16 05:51
    bblfish synchronize #272
  • Oct 16 05:51

    bblfish on 2021-10-13

    number proposal (compare)

  • Oct 16 05:21

    bblfish on draft-minutes

    (compare)

  • Oct 16 05:12

    bblfish on draft-minutes

    (compare)

  • Oct 16 05:11

    bblfish on revert-239-uc3-inheritance

    (compare)

  • Oct 16 05:11

    bblfish on bblfish-patch-1

    (compare)

  • Oct 16 04:42
    bblfish synchronize #272
  • Oct 16 04:42

    bblfish on 2021-10-13

    Update meetings/2021-10-13.md … (compare)

  • Oct 16 04:41
    bblfish synchronize #272
  • Oct 16 04:41

    bblfish on 2021-10-13

    Update meetings/2021-10-13.md … (compare)

  • Oct 15 22:03
    csarven commented #269
  • Oct 15 13:25
    csarven commented #269
  • Oct 14 15:30
    bblfish commented #275
  • Oct 14 15:28
    TallTed commented #275
  • Oct 14 15:25
    TallTed commented #275
  • Oct 14 11:50
    bblfish commented #269
  • Oct 14 11:47

    bblfish on draft-minutes

    updates and improvements after … Update meetings/2021-10-13.md … Update meetings/2021-10-13.md … and 3 more (compare)

  • Oct 14 11:36
    elf-pavlik closed #269
Henry Story
@bblfish
I'll add @kjetilk 's issue solid/authorization-panel#206
Henry Story
@bblfish
q+
justinwb @justinwb just figured out where to set my gravatar in jitsi #tmyk
Matthieu Bosquet
@matthieubosquet
Henry Story
@bblfish
q+
Aaron Coburn
@acoburn
point of clarification: the authentication panel has used various mechanisms over the years for pushing minutes
Eric Prud'hommeaux
@ericprud
[re minutes branch] other prob is that you'll also have to rebase or merge as main shifts underneath the minutes branch. adds a little impedence for folks not git-saavy
Matthieu Bosquet
@matthieubosquet
+1 to discuss performance in light of implementation experience.
elf Pavlik
@elf-pavlik
I'm :+1: for @csarven facilitating next meeting if he's still willing to and no one objects, we should also already crate pad for it
Sarven Capadisli
@csarven
elf Pavlik
@elf-pavlik
@bblfish we dedicated 40+ minutes to discuss topics which you put on today's agenda, I hope you don't see timeboxes I was applying to those topics as unfair.
bblfish
@bblfish:matrix.org
[m]
Those topics elf are what this panel is about: you know WAC and ACP. I am not sure anyone has agreed to UMA which you keep pushing for some reason.
I suggest folks open a UMA panel to discuss your proposal there.
Henry Story
@bblfish
WE just can't deal with all possible protocols that are thrown this way. Especially as we had a few actions in the summer that were never taken on.
bblfish
@bblfish:matrix.org
[m]
And even having both WAC and ACP is one too much
Aaron Coburn
@acoburn

@bblfish:matrix.org we need clarity around the interaction between AuthN and AuthZ. UMA is one viable approach.

This is something that touches on both AuthN and AuthZ and so both groups need to be involved. Giving that to a separate panel would be overkill

Kjetil Kjernsmo
@kjetilk
Just to mention an instance of a situation where a formal analysis could have resolved spec problems early. In the SPARQL 1.1. WG, there was a part of the property paths that seemed to fit pretty well, it came naturally from the rest of the language, was pretty easy to implement, and so the WG put it in. Then, a bunch of academics published a paper about it: https://dl.acm.org/doi/10.1145/2187836.2187922 So, they could have informed the spec early, but they didn't take it up with the WG, and by the time the paper was published, IIRC, the spec was in Proposed Recommendation, and so sent the WG scrambling back to the drawing board. While the WG appreciated the input and did change the spec as a result, people weren't amused, to say the least... I think formal methods has a place in the analysis of proposed specs, and it is probably cheaper to change a spec early than to discover problems empirically after implementation. That's basically what I'm trying to do with #206 . But then, I'm actually not a theorist and not well versed in formal methods, and so, given the resources we have, then yes, implementation is nice. I just want to be confident that we're not seeing O(n) behavior before we agree on a spec
bblfish
@bblfish:matrix.org
[m]
Some of the maths is not that complicated and is anyway something good developers should know. At least we should consider the points carefully.
I once met Mike Burrows who wrote the AltaVista search engine by himself pretty much. He told me how he had been happy that week thinking about 1. the mathematical idea number of steps that an operation required and 2. to have been able to get to 1/2 an instruction from that . The point was that any improvement in a core machine like that could have dramatic effects on the costs of running the search engine. In the millions of dollars easily.
kjetilk @kjetilk nods
Sarven Capadisli
@csarven
@ericprud I'm no git(hub) ninja but doesn't that apply for any branch / PR? anything will need to synch with main.
Henry Story
@bblfish

are you referring to @ericprud 's statement?

re minutes branch] other prob is that you'll also have to rebase or merge as main shifts underneath the minutes branch. adds a little impedence for folks not git-saavy

That is not really a problem as each minutes PR changes just 1 file which is both new and does not conflict with anything else. So pushing from a draft-minutes branch or other does not cause any problem. And I have not found any such problem in the past year using this system.

I think git does the right thing automatically for you, in any case.
Sarven Capadisli
@csarven
Sure, git/hub helps a lot.
But I don't recall using "draft-minutes" branch.. you brought that up recently.
All I know is we've used one-off branch for PR reasons.
Henry Story
@bblfish
We have used one-off branches yes. We should try a "draft-minutes" branch and see how that works.
One should always pull before one makes a new branch in git
Aaron Coburn
@acoburn
I have already mentioned problems with a particular "draft-minutes" branch related to access and excluding participation. Wrt having to force-push to a fixed branch like that, unless the branch is deleted upon each merge, there will be problems keeping that default-minutes branch out of conflict with main. And deleting the branch upon merge seems to undermine the argument for using a consistent name. FWIW, I am -1 on using a particular name for minutes branches
Henry Story
@bblfish
look I say we try it out to see if it works and if your problems are justified. It is easy to try out, and it is difficult to think through problems and answers theoretically. (Sometimes that is worth it, when one has long term projects like building a car. But here is is cheap to test)
Aaron Coburn
@acoburn
There was a vote in the panel mtg on this . The majority did not vote in favor of this. The majority voted to follow Sarven's proposal. Why are we still debating this?
Henry Story
@bblfish
I don't know, we just did it this way this week. I thought we were thinking longer term.
In any case why would anyone be against trying it out?
Aaron Coburn
@acoburn
We voted.... does that carry no weight? Why are we spending time on this?
Henry Story
@bblfish

This is what we voted on:

Create a PR (in whatever branch it is most suitable) immediately after meeting.
Participants have 24 (or 48) hours to provide improvements.
Then after an assignee (scribe, moderator, CG chair...) merges. This could be automated.

and only for a short period. Elf did not give us time to clarify what we were voting on
That leaves open the type of branch.
And don't tell me about the time wasted on this issue! I had a simple proposal a week ago in the previous meeting that was ignored by @csarven , who committed to main when we were discussing having a "draft" branch.
I think we actually had understanding on that at the time.
Then I spent 4 hours talking to csarven over the weekend who insisted against all to pursue the push to main idea.
For really no good reason.
Aaron Coburn
@acoburn
The next time you scribe, then use a "default-minutes" branch. If someone else ascribes, let them use what is "most convenient". We are not discussing pushing to main
Henry Story
@bblfish
ok. I think that is a good idea. We could try it out a bit and see, starting when I do that next.
elf Pavlik
@elf-pavlik
I did call for proposals on what to do with minutes just for that day. I hope solid/specification#319 will help us sort out a long term approach, and I really didn't want us to dedicate AuthZ meeting time for discussing that detail of a general process.
Sarven Capadisli
@csarven
Some of the activities overlapped. No big deal. The issue was originally discussed in this panel - that's good, bottom-up etc.. - and while that's going on, 319 opened up to reach broader consensus.
Justin Bingham
@justinwb

The Solid Editorial Team would like to increase communication with and receive feedback from community members and organizations who are actively implementing Solid compliant server or client technologies, with an aim to:

  • Learn which features or issues are high / low priority, and where applicable, adjust timelines or editorial priorities. This could impact the order in which features are integrated into Solid specifications
  • Surface, discuss, and track open questions or concerns
  • Learn the best way to structure subsequent sessions, and other mechanisms for feedback (e.g. surveys)

Date: Thursday, October 21st, 2021
Duration: 1 Hour
Start Time: UTC: 2PM / EDT (Boston): 10AM / BST (London): 3PM / CEST (Brussels): 4PM / JST (Tokyo): 11PM
URL: https://global.gotomeeting.com/join/654935701

This session is open to the public, and we welcome everyone to attend this session. In an effort to maintain a focus on implementation feedback, only individuals actively engaged in Solid compliant server or client implementation work will be queued to speak by the moderator.

To actively participate, an implementer must:

  1. Be a member of the Solid Community Group

  2. RSVP in advance to feedback@solidproject.org. Must be able to cite active implementation work. Legitimate citations include links to Github repositories, links to product descriptions on websites, or otherwise credible explanation of active work efforts.

Implementers are requested to submit questions, issues, or topics in advance to feedback@solidproject.org, ideally as part of the RSVP. Given the allotted time, space on the agenda will be limited.

Minutes will be recorded, and posted to https://github.com/solid/specification/tree/main/meetings.

Also see https://forum.solidproject.org/t/solid-implementer-feedback-session/4754.

1 reply
Justin Bingham
@justinwb
Please note - for the implementer session posted above - we’re changing the meeting to use https://meet.jit.si/solid-implementer-feedback rather than the posted gotomeeting URL.
Sarven Capadisli
@csarven
I've updated the channel topic. It'd be great if we can at least keep the Code of Conduct up there going forward. See also https://github.com/solid/deit/issues/13#issuecomment-944710055
But if all goes well and the event starts at 14:30, it is possible to have the authorization-panel meeting from 14:00 to 14:30, if people like to.