Feature suggestion: Integrate Teamtype to recover some real-time collaboration features #17

eaon commented 2026年03月03日 17:33:36 +01:00

Love to see this, but I admit I was a bit disappointed to learn that the collaborative features were removed. It is a sensible choice though given Zed's design.

Teamtype by @blinry, @zormit et al would be a nice Rust based P2P editor agnostic alternative to recover some of that functionality though: https://github.com/teamtype/teamtype

I'd be happy to help look into how integration could work.

Love to see this, but I admit I was a bit disappointed to learn that the collaborative features were removed. It is a sensible choice though given Zed's design. Teamtype by @blinry, @zormit et al would be a nice Rust based P2P editor agnostic alternative to recover some of that functionality though: https://github.com/teamtype/teamtype I'd be happy to help look into how integration could work.

krig commented 2026年03月03日 19:04:27 +01:00

Yes, this is something I have looked at! It would be great to have someone look into this, because it would be a lot of work to implement.

Yes, this is something I have looked at! It would be great to have someone look into this, because it would be a lot of work to implement.

WeetHet commented 2026年03月03日 22:17:35 +01:00

Not really, there's a language server for this: https://github.com/nonscalable/teamtype-lsp

Not really, there's a language server for this: https://github.com/nonscalable/teamtype-lsp

krig commented 2026年03月03日 23:13:11 +01:00

Oh cool, that might be easier to integrate than I thought.

Oh cool, that might be easier to integrate than I thought.

zormit commented 2026年03月04日 12:07:36 +01:00

Thanks for tagging! I haven't looked into Gram yet, but dropping some of my context that might be helpful:

• the linked language server has some drawbacks and is a prototype. Here's a discussion with details. It might bring you some initial results though :)
• the general principle is that the editor protocol should be as simple as possible, so even if you go for your own implementation it might be less work than you'd expect

Thanks for tagging! I haven't looked into Gram yet, but dropping some of my context that might be helpful: - the linked language server has some drawbacks and is a prototype. Here's a [discussion](https://github.com/teamtype/teamtype/discussions/440) with details. It might bring you some initial results though :) - the general principle is that the [editor protocol](https://teamtype.github.io/teamtype/editor-plugin-dev-guide.html) should be as simple as possible, so even if you go for your own implementation it _might_ be less work than you'd expect

tjk commented 2026年03月17日 05:29:22 +01:00

Teamtype allows LLM contributions - is that going to be compatible with Gram's mission?

Teamtype [allows LLM contributions](https://github.com/teamtype/teamtype/blob/main/CONTRIBUTING.md#generative-aillm-policy) - is that going to be compatible with Gram's mission?

krig commented 2026年03月17日 06:57:34 +01:00

@tjk wrote in #17 (comment):

Teamtype allows LLM contributions - is that going to be compatible with Gram's mission?

That’s disappointing. I’ll have to think about that.

@tjk wrote in https://codeberg.org/GramEditor/gram/issues/17#issuecomment-11736729: > Teamtype [allows LLM contributions](https://github.com/teamtype/teamtype/blob/main/CONTRIBUTING.md#generative-aillm-policy) - is that going to be compatible with Gram's mission? That’s disappointing. I’ll have to think about that.

krig commented 2026年03月17日 07:24:10 +01:00

So I am not a fan of their LLM policy (no surprise there) - or that they seem to have used an LLM to "write" their README, judging from the amount of emojis.

I think perhaps the path forward for Gram in this case might be to keep an eye at their work at making a "collaborative editing protocol", and to at some point build our own implementation of it:

https://github.com/teamtype/teamtype/discussions/483

So I am not a fan of their LLM policy (no surprise there) - or that they seem to have used an LLM to "write" their README, judging from the amount of emojis. I think perhaps the path forward for Gram in this case might be to keep an eye at their work at making a "collaborative editing protocol", and to at some point build our own implementation of it: https://github.com/teamtype/teamtype/discussions/483

zormit commented 2026年03月18日 10:37:55 +01:00

First off, I would claim we're sharing more values than you're implying, happy to have further written exchange or even a call to figure out alignment, if you're up for it :)

It makes me feel sad that we live in a world where maintainers kind of have to judge each other's content very quickly based on the number of em-dashes or number of emojis and then put them into a bucket of "tech bro" or "not tech bro" or something like that, but I get how nowadays we seem to "have to" lead with some skepticism.

As for our LLM policy: We haven't decided to exclude LLM contributions just yet, but we might? Our policy is very much a first shot and we're figuring out our path forward. Inspired by your "poke" here, blinry wrote down some thoughts in our Zulip instance. I get that you're much further and more radical in this process. It might be that you're just a bit more decisive, but in my perspective it also comes from the nature of Gram being an active fork that has bases it's core value on being against genAI and that Teamtype predates this genAI world.

So that said would like to assure you (not sure if that means anything, given we probably don't have your trust yet), your assumption about LLM usage in the README is wrong, we actually just happen to like emojis :) so far we have used LLMs very cautiously ourselves, mainly in one branch where we experimented how genAI even behaves (not having a lot of exposure to it otherwise) and that isn't even merged yet because it has this common problem of being only about 90% correct. For the PRs we obviously can't say for sure, as even if you ask people to disclose their LLM usage they might not do it - wondering how you're approaching this?

at some point build our own implementation of it

That makes sense as an option, given that you're in the mode of forking stuff anyways. I personally would rather try to join forces where values are aligned to try to avoid the famous 15 standards situation and thus make use of our limited brain-made coding capacities effectively.

Hope this makes sense and curious what you think :) in case you want to take it "offline" from this issue, feel free to reach out to us via email or mastodon or on the above mentioned Zulip instance.

First off, I would claim we're sharing more values than you're implying, happy to have further written exchange or even a call to figure out alignment, if you're up for it :) It makes me feel sad that we live in a world where maintainers kind of have to judge each other's content very quickly based on the number of em-dashes or number of emojis and then put them into a bucket of "tech bro" or "not tech bro" or something like that, but I get how nowadays we seem to "have to" lead with some skepticism. As for our LLM policy: We haven't decided to exclude LLM contributions just yet, but we might? Our policy is very much a first shot and we're figuring out our path forward. Inspired by your "poke" here, blinry wrote down some [thoughts](https://teamtype.zulipchat.com/#narrow/channel/557642-general/topic/LLM.20usage.20policy/near/579959777) in our Zulip instance. I get that you're much further and more radical in this process. It might be that you're just a bit more decisive, but in my perspective it also comes from the nature of Gram being an active fork that has bases it's **core value** on being against genAI and that Teamtype predates this genAI world. So that said would like to assure you (not sure if that means anything, given we probably don't have your trust yet), your assumption about LLM usage in the README is wrong, we actually just happen to like emojis :) so far we have used LLMs very cautiously ourselves, mainly in [one branch](https://github.com/teamtype/teamtype/commits/emacs-plugin/) where we experimented how genAI even behaves (not having a lot of exposure to it otherwise) and that isn't even merged yet because it has this common problem of being only about 90% correct. For the PRs we obviously can't say for sure, as even if you ask people to disclose their LLM usage they [might not do it](https://github.com/teamtype/teamtype/pull/498#issuecomment-4056084663) - wondering how you're approaching this? > at some point build our own implementation of it That makes sense as an option, given that you're in the mode of forking stuff anyways. I personally would rather try to join forces where values are aligned to try to avoid the famous [15 standards situation](https://xkcd.com/927/) and thus make use of our limited brain-made coding capacities effectively. Hope this makes sense and curious what you think :) in case you want to take it "offline" from this issue, feel free to reach out to us via [email](https://teamtype.github.io/teamtype/learn-from-us.html#open-invitation-ask-us-anything) or [mastodon](https://fosstodon.org/@teamtype) or on the above mentioned [Zulip instance](https://teamtype.zulipchat.com/).

krig commented 2026年03月18日 11:05:26 +01:00

It makes me feel sad that we live in a world where maintainers kind of have to judge each other's content very quickly based on the number of em-dashes or number of emojis and then put them into a bucket of "tech bro" or "not tech bro" or something like that, but I get how nowadays we seem to "have to" lead with some skepticism.

I'm right there with you.. what a mess everything has become.

So that said would like to assure you (not sure if that means anything, given we probably don't have your trust yet), your assumption about LLM usage in the README is wrong, we actually just happen to like emojis :)

Apologies! This is something I struggle with, personally. I don't want to jump to judgement, but I am also busy/tired/all those things and make mistakes. Condemning someone as a gen-ai user incorrectly does feel worse than being wrong in the opposite direction. I keep telling myself to be less quick to judgement, but yeah I guess it should be no surprise that I have strong feelings on the subject.

I am also less hardline on this topic than some others. I did fork Zed even though it is "tainted", the website for gram is made using an SSG which was built using gen AI. I don't like that; I didn't know it when I started using it, but here we are, I haven't mustered enough outrage to rebuild it.

That makes sense as an option, given that you're in the mode of forking stuff anyways. I personally would rather try to join forces where values are aligned to try to avoid the famous 15 standards situation and thus make use of our limited brain-made coding capacities effectively.

I would love to fork less, lets just say that!

Hope this makes sense and curious what you think :) in case you want to take it "offline" from this issue, feel free to reach out to us via email or mastodon or on the above mentioned Zulip instance.

I'll be in touch.

> It makes me feel sad that we live in a world where maintainers kind of have to judge each other's content very quickly based on the number of em-dashes or number of emojis and then put them into a bucket of "tech bro" or "not tech bro" or something like that, but I get how nowadays we seem to "have to" lead with some skepticism. I'm right there with you.. what a mess everything has become. > So that said would like to assure you (not sure if that means anything, given we probably don't have your trust yet), your assumption about LLM usage in the README is wrong, we actually just happen to like emojis :) Apologies! This is something I struggle with, personally. I don't _want_ to jump to judgement, but I am also busy/tired/all those things and make mistakes. Condemning someone as a gen-ai user incorrectly does feel worse than being wrong in the opposite direction. I keep telling myself to be less quick to judgement, but yeah I guess it should be no surprise that I have strong feelings on the subject. I am also less hardline on this topic than some others. I did fork Zed even though it is "tainted", the website for gram is made using an SSG which was built using gen AI. I don't like that; I didn't know it when I started using it, but here we are, I haven't mustered enough outrage to rebuild it. > That makes sense as an option, given that you're in the mode of forking stuff anyways. I personally would rather try to join forces where values are aligned to try to avoid the famous 15 standards situation and thus make use of our limited brain-made coding capacities effectively. I would love to fork less, lets just say that! > Hope this makes sense and curious what you think :) in case you want to take it "offline" from this issue, feel free to reach out to us via email or mastodon or on the above mentioned Zulip instance. I'll be in touch.

tjk commented 2026年03月18日 16:34:44 +01:00

@krig wrote in #17 (comment):

I'll be in touch.

I hope the discussion can be public, and at least linked from here, if not had here. Or at least the decision. Of course you can make your own judgments, but Gram is being circulated as an editor pushing back against AI, and (post-fork) taking a dependency that used AI would seem to go against the way some have interpreted the mission. Switching editors (and contributing to them) is an investment, so I think understanding this as a type of policy would be helpful.

@krig wrote in https://codeberg.org/GramEditor/gram/issues/17#issuecomment-11777742: > I'll be in touch. I hope the discussion can be public, and at least linked from here, if not had here. Or at least the decision. Of course you can make your own judgments, but Gram is being circulated as an editor pushing back against AI, and (post-fork) taking a dependency that used AI would seem to go against the way some have interpreted the mission. Switching editors (and contributing to them) is an investment, so I think understanding this as a type of policy would be helpful.

krig commented 2026年03月18日 17:01:50 +01:00

I hope the discussion can be public, and at least linked from here, if not had here.

Oh yeah definitely.

From the sound of it the AI policy is still being discussed. Maybe we can have an influence there. In the Zulip they are citing the Zig project as an inspiration and they have a "Strict No LLM / No AI Policy" so hopefully Teamtype may land there as well.

> I hope the discussion can be public, and at least linked from here, if not had here. Oh yeah definitely. From the sound of it the AI policy is still being discussed. Maybe we can have an influence there. In the Zulip they are citing the Zig project as an inspiration and they have a "Strict No LLM / No AI Policy" so hopefully Teamtype may land there as well.

alerque commented 2026年04月22日 12:48:19 +02:00

As of today the Teamtype project's ongoing discussion has reached a milestone and the official stance on LLM contributions has been stated — it is now much more concrete than the previous "maybe not, we'll see"; it is now "no thank you, hard pass on any LLM generated code". See the changes in the PR here.

See also this tracking issue related to Zed.

As of today the Teamtype project's [ongoing discussion](https://teamtype.zulipchat.com/#narrow/channel/557642-general/topic/LLM.20usage.20policy) has reached a milestone and the official stance on LLM contributions has been stated — it is now much more concrete than the previous "maybe not, we'll see"; it is now "no thank you, hard pass on any LLM generated code". See the changes in [the PR here](https://github.com/teamtype/teamtype/pull/519). See also [this tracking issue related to Zed](https://github.com/teamtype/teamtype/issues/472).

krig commented 2026年04月22日 13:37:17 +02:00

That's great, certainly makes Teamtype support viable for us!

That's great, certainly makes Teamtype support viable for us!

ItsHarper commented 2026年04月22日 19:44:59 +02:00

I should probably mention that the Zedless lead has explicitly mentioned this as something that would be great to collaborate on with the Gram project: https://github.com/zedless-editor/zedless/issues/86#issuecomment-4061067942

BTW, active development on Zedless has moved here: https://github.com/zedless-editor/zedless-patches

I should probably mention that the Zedless lead has explicitly mentioned this as something that would be great to collaborate on with the Gram project: https://github.com/zedless-editor/zedless/issues/86#issuecomment-4061067942 BTW, active development on Zedless has moved here: https://github.com/zedless-editor/zedless-patches

krig commented 2026年05月14日 22:59:40 +02:00

Hello,

I've decided to go through and close issues that I don't intend to fix. If it's a feature request for something that I haven't planned to do, then I would encourage you as the reader to fix it yourself! It's open source, I'm guessing most people who are using a code editor are coders, and it's good for you to learn new things. I've come to realize that I can't fix WGPU issues on a particular piece of hardware for example. Whoever has that problem will have to solve it so they can verify that the fix actually works.

If it's a packaging thing, like providing packages for a particular OS, Linux distro or architecture, then all I can say is that I have tried and there just isn't enough time in my life to support everything people want. What I have done is hook up this repo to a Github mirror with actions enabled: https://github.com/GramEditor/gram. My suggestion to anyone who needs or wants a particular build is to make a PR that adds build support that way.

Hello, I've decided to go through and close issues that I don't intend to fix. If it's a feature request for something that I haven't planned to do, then I would encourage you as the reader to fix it yourself! It's open source, I'm guessing most people who are using a code editor are coders, and it's good for you to learn new things. I've come to realize that I can't fix WGPU issues on a particular piece of hardware for example. Whoever has that problem will have to solve it so they can verify that the fix actually works. If it's a packaging thing, like providing packages for a particular OS, Linux distro or architecture, then all I can say is that I have tried and there just isn't enough time in my life to support everything people want. What I _have_ done is hook up this repo to a Github mirror with actions enabled: https://github.com/GramEditor/gram. My suggestion to anyone who needs or wants a particular build is to make a PR that adds build support that way.

alerque commented 2026年05月17日 11:33:22 +02:00

I understand FOSS maintainer overload (believe me, the understanding is guttural) but closed issues send a different signal than "open to contributions". They send a message that the project is not open to contributions or doesn't want a specific feature. Closing things as "won't fix" if the project has no intention of accepting contributions in a direction is one thing, but closing issues with ongoing discussion about things that would be accepted is not community friendly.

Will this project be willing to accept this as a feature if people jump in and work on it? Because I've already started playing around with it and am working from the Teamtype side to make the Rust crate API usable for building into an editor like this without needing the external tooling, and I think that's a promising direction. Having this side of the discussion shut down is not encouraging.

If this is a community effort –as opposed to a one man show– where multiple maintainers are around and at least one of them would consider facilitating this getting merged as a feature if others like me jump in to get a PR together then I would request this be re-opened as a signal in that direction and a visible place for ongoing discussion about how it would come together. There will be more to discuss even before a working PR takes shape and a closed issue is not a good place for that.

I understand FOSS maintainer overload (believe me, the understanding is guttural) but closed issues send a different signal than "open to contributions". They send a message that the project is **not** open to contributions or doesn't want a specific feature. Closing things as "won't fix" if the project has no intention of accepting contributions in a direction is one thing, but closing issues with ongoing discussion about things that *would be* accepted is not community friendly. Will this project be willing to accept this as a feature if people jump in and work on it? Because I've already started playing around with it and am working from the Teamtype side to make the Rust crate API usable for building into an editor like this without needing the external tooling, and I think that's a promising direction. Having this side of the discussion shut down is not encouraging. If this is a community effort –as opposed to a one man show– where multiple maintainers are around and at least one of them would consider facilitating this getting merged as a feature if others like me jump in to get a PR together then I would request this be re-opened as a signal in that direction and a visible place for ongoing discussion about how it would come together. There will be more to discuss even before a working PR takes shape and a closed issue is not a good place for that.

krig commented 2026年05月17日 18:28:59 +02:00

Will this project be willing to accept this as a feature if people jump in and work on it? Because I've already started playing around with it and am working from the Teamtype side to make the Rust crate API usable for building into an editor like this without needing the external tooling, and I think that's a promising direction. Having this side of the discussion shut down is not encouraging.

To clarify (which I tried to do in the message above but evidently failed), my intent was not to shut down discussion or mark as WONTFIX. My main problem is with the Codeberg user interface, inherited from Github. Right now, bugs and feature requests are mixed up in one single list and the psychological effect on me at least has not been great.

When it comes to bugs, I want to fix them all and my goal is to reduce the number to zero. If someone submits a patch that's great, but I at least right now I care enough to want to try to solve things myself. It also helps me understand the code better.

Features, on the other hand, is something I want to be a lot more careful about. It's not that I want to reject features. But my experience is that if I do accept a new feature, the responsibility to maintain it most likely becomes mine. Because of that, I want to raise the threshold for feature requests to ensure that whoever is asking for it cares enough to stay involved in making sure it keeps working.

My idea was to try to move the feature requests to the Wiki. Keep the discussion but make it clearer that it's a long term commitment rather than just dropping a patch. I know it's not the usual approach but the usual approach is not great, and I see other projects experiment with things like limiting who can contribute which I also don't really want to do.

@alerque I didn't know that this was something you were already working on, but I am absolutely still open to merging support for Teamtype, just to make that clear.

> Will this project be willing to accept this as a feature if people jump in and work on it? Because I've already started playing around with it and am working from the Teamtype side to make the Rust crate API usable for building into an editor like this without needing the external tooling, and I think that's a promising direction. Having this side of the discussion shut down is not encouraging. To clarify (which I tried to do in the message above but evidently failed), my intent was not to shut down discussion or mark as WONTFIX. My main problem is with the Codeberg user interface, inherited from Github. Right now, bugs and feature requests are mixed up in one single list and the psychological effect on me at least has not been great. When it comes to bugs, I want to fix them all and my goal is to reduce the number to zero. If someone submits a patch that's great, but I at least right now I care enough to want to try to solve things myself. It also helps me understand the code better. Features, on the other hand, is something I want to be a lot more careful about. It's not that I want to reject features. But my experience is that if I do accept a new feature, the responsibility to maintain it most likely becomes mine. Because of that, I want to raise the threshold for feature requests to ensure that whoever is asking for it cares enough to stay involved in making sure it keeps working. My idea was to try to move the feature requests to the Wiki. Keep the discussion but make it clearer that it's a long term commitment rather than just dropping a patch. I know it's not the usual approach but the usual approach is not great, and I see other projects experiment with things like limiting who can contribute which I also don't really want to do. @alerque I didn't know that this was something you were already working on, but I am absolutely still open to merging support for Teamtype, just to make that clear.

cyrneko commented 2026年05月31日 20:44:33 +02:00

a bit late here, but @krig I think a separate repository with just the Issues tab enabled titled Feature-Requests may be useful.

a bit late here, but @krig I think a separate repository with just the `Issues` tab enabled titled `Feature-Requests` may be useful.

alerque commented 2026年06月01日 10:40:37 +02:00

@cyrneko I've seen than done but find it very awkward both as a user and as a maintainer. There isn't a clean hard line break between feature requests and bug reports and inevitably some things get opened on the wrong side of the split. Then when feature requests turn into work in progress it is hard to track them when they are on a different repo than the code.

I would suggest tags/labels are the right solution here and just giving some convenience links to issues tagged bug / issues tagged feature-request / etc. would handle this fine. The trouble I see is that there isn't a label for feature requests so they are hard to filter for or filter out of other queries.

@cyrneko I've seen than done but find it very awkward both as a user and as a maintainer. There isn't a clean hard line break between feature requests and bug reports and inevitably some things get opened on the wrong side of the split. Then when feature requests turn into work in progress it is hard to track them when they are on a different repo than the code. I would suggest tags/labels are the right solution here and just giving some convenience links to [issues tagged bug](https://codeberg.org/GramEditor/gram/issues?labels=1262791) / issues tagged feature-request / etc. would handle this fine. The trouble I see is that there isn't a label for feature requests so they are hard to filter for or filter out of other queries.

krig commented 2026年06月02日 22:54:01 +02:00

@alerque @cyrneko I've added a feature request label again. Let's see how it goes :)

@alerque @cyrneko I've added a feature request label again. Let's see how it goes :)