Because we decided to build an executable specification for ActivtyPub at Human-Connection: https://github.com/Human-Connection/Nitro-Fediverse
I think more projects might benefit from the cucumber features, you just have to implement your own project-specific step definitions.
By the way: We’re meeting bi-weekly on Thursday 1pm UTC (15mins from now):
FWIW, “resurrected” is not quite accurate - the project never ceased - what happened was that the initial design discussions pretty much ran their course after a few months - the remaining work to be done is primarily in prototyping - there was simply not as much to discuss publicly for that period - so, one could get the impression that the work had stalled if only watching the mailing list
furthermore, if one was only watching the github repo, the impression would be that almost nothing had ever been accomplished - that was a case of the default “BDFL” management structure of a github repo working against the effort far more than it was helping - most notably because the no-derivatives license on the github repo literally prevents anyone else from working on it - the repo owner thwarted our every attempt to change the license to something more permissive; so that the efforts of peers community and others could be included in the github repo (ideally as a mirror of the notabug repo) - unfortunately he never gave anyone else write access to the repo, nor moderation rights to the mailing list; and he has not interacted with the mailing list nor github repo in over six months - that is why there is still nothing but a README in that repo
though it apparantly attracted a lot of interest, that github repo and mailing list had no potential to become anything more than discussion forua, because no one participating in the discussions agreed that their work would be published under a no-derivatives license - that was added to the github repo very prematurely by the repo owner before any discussions began, most importantly, before any discussions regarding an acceptable license began - it was one of the first issues raised, the consensus was unanimus that it needed to be changed; but that did not happen - so once the initial discussions had run their course, there was nothing more that could be done on github or the mailing list, other than posting occasional updates on how the general interest was taking form in various places and about similar discussions in other venues such as this one
to be clear, fr33domlover and the peers community had been discussing and working on repo federation for years before the “git-pub” discussions last summer; of which, the name ‘ForgeFed’ was the one tangible item agreed upon by consensus - those of us who wanted to continue the actual work beyond those hastily “knee-jerk” motivated discussions, had no option other to continue the work on notabug (plus IRC) as we had been doing all along - beyond engaging the new crowd of interested people in discussion, the most that we could do in those venues was to invite those who are interested to the IRC channels and the notabug repo where the license allows open collaboration - that was the primary reason we contacted them in the first place - if i had known that the license would never be changed, i would have stopped right there - other than meeting folks from a few other related projects such as social-home and git-dit, the most useful information we got from it, is that a lot of people wanted forges to support activity-pub - activity-pub was already considered to be a viable option for the inter-op communication layer; but we were not aware of how popular it was
now that the prototyping is coming to fruition, we are considering to open a new web-based discussion forum, perhaps on this server, as a replacement for the github issue tracker, which is associated with an now apparently defunct repo
the other thing i would like to underline, is that it is not at all important whether or not gitlab or any other forge upstream is willing to implement ForgeFed interoperability - the free software licenses of the mature self-hosted forges (e.g. gitlab, pagure, gogs/gitea and several others) fully permit anyone who is interested to write that implementation - endorsement by the upstream is not required and is of no particular value to self-hosting admins or their users - reference implementations in python and ruby are planned, that would ease implementation in pagure and gitlab - if someone wants to make one in PHP and/or golang, that would cover the majority of the mature self-hosted forges
Thank you for setting me straight Bill. And for shedding light on the efforts over the past year. Glad to hear things have been moving, and I have also had the pleasure to talk to fr33domlover in the socialcg IRC room in the interim.
coolness @_cj - i did not realize you were the same CJ from the git-federation discussions - the forge-fed README links to the go-fed project
had i known that, i would not have lectured at such length - i was compelled to clear the air about all that for the benefit of those who were only paying attention to koalas github repo - now that we have established a proper web presence we plan to post progress updates more regularly
how is go-fed coming along? - are you interested in a forum here as well?
v1 is almost stable, ramping back up to develop on it. Thanks for asking!
I am not opposed to having one, but am not sure whether it is appropriate or not: go-fed/activity is a library, so its users are other developers, not general users. The other areas here are all for end-user-facing projects. If management wants to keep it that way, that’s fine & I understand.
agreeing with how, the forge-fed project is also useful mainly to implementers - other than vervis, the only artifacts it will produce at first are the spec documents and some reference implementations or bridges - the idea has been kicked around that there could be a command-line client or desktop client at some later time; but nothing user-facing is currently planned
and of course, the activity-pub project itself is uninteresting to users
in a less than ideal context though (actually totally off-topic for this thread) - there are surely still many watching the github repo and mailing list that are not aware of anything that happened since the person who set those up stopped attending to the discussions last summer - fr33domlover established a mastodon presence last week which seems to be drawing attention too, so its probably time to make some announcement on github
my thanks to the admins for taking forge-fed and go-fed on board
Coming back to the topic, I agree with the OP that there’s a need for areas on this forum where people from different projects can gather to talk about federating specific types of data; long-form blogs, events, maps, etc. For now, such discussions could be created as topic threads in the ActivityPub category. But would it be best for each data type to have its own category? That way multiple discussions could be carried out in parallel more easily, some more general, some addressing very specific technical nuts and bolts. The ForgeFed category is an example of how this might look in practice.
I considered the same thing with regard to the Federated Events discussion, since the one-software-one-category pattern does not seem to apply there. I wish there were a split around media functionality, so that each specific type of media could be covered, encouraging small apps to develop around specific problems that could then be solved altogether by cooperation rather than competition – each is important, but setting up effective ways for cooperation seems the way to go, especially when considering federated functionality.