jaywink commented on issue peers/forgefed#92

> if that's GitLab CE, Free software, then yeah it would be a candidate :) there's also Framagit which is GitLab CE

4 years ago

jaywink commented on issue peers/forgefed#92

https://git.feneas.org ? :)

4 years ago

jaywink commented on issue peers/forgefed#82

Numeric ID's don't really work in a federated environment. This would be a non-standard way of mentioning in ActivityPub and requires additional implementation for platforms. Also, consider;

4 years ago

jaywink created pull request peers/forgefed#74

4 years ago

jaywink created new branch link-to-website at jaywink/forgefed

4 years ago

jaywink forked a repository to jaywink/forgefed

4 years ago

jaywink opened issue peers/forgefed#73

4 years ago

jaywink commented on issue peers/forgefed#7

I believe I already answered to all the above in my reasoning why I think double ID's via Offer are not the way things should work. You can't have federation and centralization at the same time, you have to choose which one you want. And I think this way it's more "centralized" than "federated". In a federated environment, data is stored over many places and the author of whatever the data is has some control over that data. That is what federation is. Forgefed wont be federation if it tries to also keep centralization.

4 years ago

jaywink commented on issue peers/forgefed#58

> It's possible to first Create the ticket and then Offer it in a separate activity, but as long as there's no need for that, I prefer to go simple and just use Offer alone.

4 years ago

jaywink commented on issue peers/forgefed#7

Let's forget the Offer for a while. I assume it comes from the fact that you want to create another object "owned" by the repository.

4 years ago

jaywink commented on issue peers/forgefed#7

> We'll do it the same way for merge requests; the user controls the Offer object and the stuff inside, and if the offer is Accepted, then repo side creates its own copy that it controls.

4 years ago

jaywink commented on issue peers/forgefed#58

I've got a little fever so might not be thinking straight. But why do we have the `Offer` at all? I would assume `Create` would be more normal.

4 years ago

jaywink commented on issue peers/forgefed#58

> IDEA: Let's decide that for now we define only subtypes that have distinct functionality needed for our spec. Otherwise, just use plain Ticket. We'll separately look into having a standard set of ticket subtypes, if we decide we want that.

4 years ago

jaywink commented on issue peers/forgefed#3

> Hmm is there something to gain from making Ticket a subtype of Note? The only thing that comes to mind is display, but you can always grab the name and the content of any object and display them, even if it's not a subtype of Note.

4 years ago

jaywink commented on issue peers/forgefed#60

I guess the idea here comes from a typical way of namespacing in GitHub, GitLab, notabug, etc, where `peers` is the organization here (with `id: https://notabug.org/peers` and this repository would have `id: https://notabug.org/peers/forgefed` and `attributedTo: https://notabug.org/peers`.

4 years ago

jaywink commented on issue peers/forgefed#62

For protocols, how about making it an object:

4 years ago

jaywink commented on issue peers/forgefed#57

+1 for the standard `followers`.

4 years ago

jaywink commented on issue peers/forgefed#25

I'd like to ask the question: do we really want all this data in the payloads? Because to me it seems like it is duplicating the data in git. Would ref, message, author and timestamp be enough?

5 years ago

jaywink commented on issue peers/forgefed#11

That sounds sane, especially the 1.

5 years ago